[9] RFR(S): 8073670: TypeF::eq and TypeD::eq do not handle NaNs correctly

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Feb 26 21:57:01 UTC 2015


On 2/26/15 1:49 PM, Zoltán Majó wrote:
> Hi Vladimir,
>
>
> thank you for the review!
>
> On 02/26/2015 07:49 PM, Vladimir Kozlov wrote:
>> Hi, Zoltan
>>
>> The test misses copyright header otherwise changes look good.
>
> I added the copyright header. Here is the new webrev:
>
> http://cr.openjdk.java.net/~zmajo/8073670/webrev.01/

Looks good.

>
>> Please, acknowledge Stefan Anzinger as contributor in changeset. He
>> identified the problem and proposed original fix.
>
> Thanks for pointing that out. I will acknowledge Stefan in the changeset.

Thanks,
Vladimir

>
> Thank you and best regards,
>
>
> Zoltan
>
>>
>> Thanks,
>> Vladimir
>>
>> On 2/26/15 1:32 AM, Zoltán Majó wrote:
>>> Hi,
>>>
>>>
>>> please review the following patch.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073670
>>>
>>> Problem: The C2 compiler treats different NaN values as equivalent. As a
>>> result, if there are multiple NaN values used in a single method, those
>>> values can potentially be folded into a single value. That behavior is
>>> not consistent with the behavior of C1 and the interpreter that always
>>> treat different NaN values as different.
>>>
>>> Solution: Change TypeF:eq and TypeD:eq to compare NaN values using a
>>> bitwise comparison (instead of using the g_isnan() function).
>>>
>>> Webrev: http://cr.openjdk.java.net/~zmajo/8073670/webrev.00/
>>>
>>> Testing: Added compiler/c2/DifferentNaNFoldingTest.java. Test behaves as
>>> expected if
>>>
>>> - executed locally on linux_x64, solaris_sparc, solaris_x64 with/without
>>> fix
>>> - executed in JPRT on all architectures targeted by the
>>> hotspot_compiler_1 target with/without fix
>>>
>>> Thank you and best regards,
>>>
>>>
>>> Zoltan
>>>
>


More information about the hotspot-compiler-dev mailing list