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

[Vladimir Kozlov]

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
>