[9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux

Zoltán Majó zoltan.majo at oracle.com
Thu Mar 12 12:43:17 UTC 2015


please review the following small patch.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074869

Problem: On Linux, the C2 code generator can replace the value -0.0f 
with +0.0f (and also the value -0.0d with +0.0d). The reason is that in 
some *.ad files both the value -0.0f and +0.0f is treated as being +0.0f 
and can therefore be replaced with an immediate +0.0f embedded into an 

For example, in the sparc.ad file, the 'fpclass' function is used to 
decide if a float node's content is +0.0:

predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO));

On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and 
FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are 
distinguished by the compiler.

On Linux, however, 'fpclass' is not available and therefore 'fpclassify' 
is used. 'fpclassify' does not distinguish between ±0.0f, it returns 
FP_ZERO for both +0.0f and -0.0f.

Solution: Instead of 'fpclass', use cast float->int and double->long to 
check if value is +0.0f and +0.0d, respectively. This logic is already 
use on some architectures, for example on x86_32 and on x86_64.

As 'fpclass' is not used any more, remove its declarations from 
globalDefintions_*. The include of ieeefp.h must be kept as we rely on 
some other functionality from this header on solaris.

Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/

- JPRT testing on all supported platforms (does *not* include aarch64 
and ppc64)

- manual testing on aarch64:

All DaCapo benchmarks with the small input size. I used the default JVM 
flags and tested the VM w/ and w/o the fix. All benchmarks pass except 
eclipse. For eclipse, the same Java-level failure appears both w/ and 
w/o the fix, so I think the problem with eclipse is not due to these 

I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. 
Eclipse fails in this case as well. Additionally, tradebeans and 
tradesoap fail with a Java-level failure. As the failure happens also 
with both builds (w/ and w/o the fix), I don't think the problem is 
caused by these changes either.

- no testing on ppc64: I don't have access to a ppc64 machine. Could 
somebody with access to a ppc64 machine please build and test the VM 
with this patch (and then maybe confirm that it works)?

Thank you and best regards,


More information about the hotspot-compiler-dev mailing list