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

[Vladimir Kozlov]

Added CC list I missed in my previous reply.

On 3/26/19 10:56 AM, Aleksey Shipilev wrote:
> On 3/26/19 6:52 PM, Vladimir Kozlov wrote:
>> I don't think we should have stub_addr check asserts in library_call.cpp (in graphKit it is fine).
>> It is normal if an implementation is done only on some platforms. Consider it as
>> Matcher::match_rule_supported() check we have in some intrinsics.
> 
> 
> I think I misplaced one of the assert blocks. Look here:
>   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.

Thanks,
Vladimir

> 
> -Aleksey
>