JDK-6717150 : improper constant folding of subnormal strictfp multiplications and divides
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs13
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86
  • Submitted: 2008-06-20
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs13Fixed
JCK 6b
JDK 6u6p b01

solaris-x86 32-bit

test lang/TYPE/type044/type04404/type04404.html fails id -server -Xcomp specified.

steps to reproduce:

run the command

/export/JDK/jre1.6.0_06/bin/java -server -Xcomp -Xconcgc -Djava.awt.headless=true -Djava.ext.dirs=/net/stt-13.russia/export/stt/jck_promotions/6b/b24/binaries/JCK-runtime-6b/lib/extensions:/export/JDK/jre1.6.0_06/lib/ext:/export/JDK/jre1.6.0_06/jre/lib/ext -Xfuture -classpath /net/stt-13.russia/export/stt/jck_promotions/6b/b24/binaries/JCK-runtime-6b/classes:/export/JDK/jre1.6.0_06/lib/tools.jar -Djava.security.policy=/net/stt-13.russia/export/stt/jck_promotions/6b/b24/binaries/JCK-runtime-6b/lib/jck.policy javasoft.sqe.tests.lang.type044.type04404.type04404

it will report:
type04404: failure # 1
type04404: failure # 2

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/78c058bc5cdc

EVALUATION This looks to be a compile time folding variant of 4462517. The fix will likely be to avoid folding doouble multiply and divides in strictfp mode.

EVALUATION Fails on d32 when compiling javasoft/sqe/tests/lang/type044/type04404/type04404.run. Not sure exactly what triggered this change in testing. Older VMs will uncommon_trap in this method; newer VMs that compile the method as expected reduce the entire method to a simple return. When C2 compiles this method incorrectly, a dmul bytecode is wrongly folded by MulDNode::mul_ring(), with a result that is off by one bit. A subsequent CmpD then always folds as not equal. This may be a strict fp issue, but needs more investigation. *** (#1 of 1): [ UNSAVED ] ###@###.###