RFR (XS) 8220198: Lots of com/sun/crypto/provider/Cipher tests fail on x86_32 due to missing SHA512 stubs

[Tobias Hartmann]

Hi Aleksey,

looks good to me too.

Best regards,
Tobias

On 26.03.19 19:49, Vladimir Kozlov wrote:
> On 3/26/19 11:39 AM, Aleksey Shipilev wrote:
>> On 3/26/19 7:33 PM, Vladimir Kozlov wrote:
>>> On 3/26/19 10:56 AM, Aleksey Shipilev wrote:
>>>> On 3/26/19 6:52 PM, Vladimir Kozlov wrote:
>>>>  
>>>> http://cr.openjdk.java.net/~shade/8220198/webrev.02/src/hotspot/share/opto/library_call.cpp.sdiff.html
>>>>
>>>>
>>>> In first instance, we are about to call make_runtime_call with "stubAddr == NULL", which is
>>>> going to
>>>> assert there. If there is only the "return false", then it would silently disable the intrinsic
>>>> without exposing the actual bug. That is not good.
>>>>
>>>> In second instance, we do know the intrinsic is enabled, because we are under (klass_SHA_name !=
>>>> NULL) and going for inline_sha_implCompressMB generation with potentially NULL stub_addr. That
>>>> method would call make_runtime_call with NULL then, and assert there, but then we have the same
>>>> hidden problem as in first instance.
>>>
>>> Agree. There are asserts or checks for flags which complement your new assert.
>>> Your assert will catch cases when flag is set but stub is not generated as in this bug.
>>
>> Okay, good. So to be clear, you are agreeing with that webrev, right?
>>    http://cr.openjdk.java.net/~shade/8220198/webrev.02/
> 
> Yes, it is good.
> 
> Vladimir
> 
>>
>> -Aleksey
>>