[9] RFR(S): 8073670: TypeF::eq and TypeD::eq do not handle NaNs correctly
Zoltán Majó
zoltan.majo at oracle.com
Thu Feb 26 21:49:07 UTC 2015
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/
> 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.
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