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
Posted Date : 2008-06-20 08:42:17.0

N/A

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 ]   xxxxx@xxxxx  
Posted Date : 2008-06-20 19:24:35.0

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.
Posted Date : 2008-06-23 19:02:25.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/78c058bc5cdc
Posted Date : 2008-10-14 16:34:15.0