Two tests in runThese can fail due to wrong constant folding of the drem bytecode:

[Enter:javasoft.sqe.tests.lang.expr303.expr30303.expr30303]
expr30303: failure #12
#Failed; javasoft.sqe.tests.lang.expr303.expr30303.expr30303; (1,0,0,1,0)
[Exit:javasoft.sqe.tests.lang.expr303.expr30303.expr30303]

[Enter:javasoft.sqe.tests.vm.instr.drem.drem003.drem00301m1.drem00301m1]
#Failed; javasoft.sqe.tests.vm.instr.drem.drem003.drem00301m1.drem00301m1; (1,0,0,1,0)
[Exit:javasoft.sqe.tests.vm.instr.drem.drem003.drem00301m1.drem00301m1]


The bug only affects the expression x%x, where x is Double.POSITIVE_INFINITY.

This only occurs when an actual ModDNode is created, because the bug is in ModDNode::Value.

The affected platform is x86/32, because there is a match rule for ModD in that AD file.

This problem has always been in C2, but it did not manifest because the two tests have many different subtests, and until now the code generated by -Xcomp has deoptimized before executing any compiled code for the failing subtest.

The problem has been in the code for years, but only shows up now in pre-integration testing to the well-known classes optimization (6652736), which slightly reduces deoptimization behavior.