JDK-8211100 : HotSpot C1 issue with comparing long numbers on x86 32-bit
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2018-09-25
  • Updated: 2022-10-06
  • Resolved: 2019-03-20
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 11 JDK 12 JDK 13
11.0.17-oracleFixed 12.0.2Fixed 13 b13Fixed
Related Reports
Relates :  
Description
Test case for this issue:

public class app {
    public static void main(String[] args) {
        Integer cnt = 100;
        if (args.length > 0) {
            cnt = Integer.parseInt(args[0]);
        }

        for (int i = 0; i < cnt; i++) {
            test(4558828911L,
                 4294967296L);
        }
    }

    private static void test(long one, long two) {
        while (true) {
            if (one >= two) {
                break;
            }
        }
    }
}

OPTS="-XX:+PrintCompilation -XX:CompileOnly=app.test -XX:CompileCommand=quiet"
$JAVA_HOME/bin/java $OPTS app 10000

The issue is specific to 32-bit where C1 generated code enters infinite loop.
Comments
This breaks x86_32, needs to be fixed sooner, adding jdk11u-critical-request.
26-03-2019

Fix Request (12u, 11u) This fixes a very serious miscompilation on x86_32. Patch applies cleanly to 11u and 12u. Passes tier1 tests on x86_64 for both 11u and 12u. java/util/Arrays/Sorting.java and compiler/c1/Test8211100.java fail without the patch on x86_32 in both 11u and 12u, and pass with the patch.
25-03-2019

URL: http://hg.openjdk.java.net/jdk/jdk/rev/af3f568cbd2d User: dcherepanov Date: 2019-03-20 08:52:20 +0000
20-03-2019

Reviving the review thread https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-March/033040.html
06-03-2019

Aleksey, The review has been started but Igor's comments have not yet been fully addressed http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030827.html I'll follow-up on Igor's comments later today.
06-03-2019

Do we know what is the hold up? Seems to be in progress since Sep 2018. Dmitry, are you still working on this? JDK-8201447 regressed x86_32 in tier1 in jdk/jdk, and it fails in 11u too, I think. At least java/util/Arrays/Sorting.java is affected: $ CONF=linux-x86-server-fastdebug make run-test TEST=java/util/Arrays/Sorting.java STDERR: *** TEST FAILED - Check merge sorting. Array is not sorted at 40-th position: -147 and -148. java.lang.RuntimeException: Test failed - see log file for details at Sorting.failed(Sorting.java:1012) at Sorting.failedSort(Sorting.java:1016) at Sorting.checkSorted(Sorting.java:1145) at Sorting.checkSorted(Sorting.java:1115) Apply this (Dmitry's webrev from RFR): diff -r 7a72441858bb src/hotspot/share/c1/c1_LIRGenerator.cpp --- a/src/hotspot/share/c1/c1_LIRGenerator.cpp Tue Feb 26 14:57:23 2019 +0530 +++ b/src/hotspot/share/c1/c1_LIRGenerator.cpp Tue Mar 05 23:01:15 2019 +0100 @@ -3285,7 +3285,9 @@ void LIRGenerator::increment_backedge_counter_conditionally(LIR_Condition cond, LIR_Opr left, LIR_Opr right, CodeEmitInfo* info, int left_bci, int right_bci, int bci) { if (compilation()->count_backedges()) { - __ cmp(cond, left, right); + LIR_Opr left_copy = new_register(left->type()); + __ move(left, left_copy); + __ cmp(cond, left_copy, right); LIR_Opr step = new_register(T_INT); LIR_Opr plus_one = LIR_OprFact::intConst(InvocationCounter::count_increment); LIR_Opr zero = LIR_OprFact::intConst(0); $ CONF=linux-x86-server-fastdebug make run-test TEST=java/util/Arrays/Sorting.java [PASS!]
05-03-2019

Hi [~dcherepanov], Request your help info regarding this task. Understood review comments were received for your initial RFR-webrev submission for 8211100. But could not find update on same. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030735.html Currently are you are targeting this fix for JDK 12 ? Otherwise you may please change the 'Fix Version' here to 'tbd'. Thank you,
22-11-2018

ILW = C1 generates incorrect code, on x86_32, disable profiling or compilation = HMM = P2
25-09-2018

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030704.html
25-09-2018

This issue is a regression of the fix for backedge profiling (https://bugs.openjdk.java.net/browse/JDK-8201447) that implements using cmp/cmove and this has side effect for x86 32-bit where compare implemented using sub/sbb. The cmp/cmove for the backedge counter updates the left operand (full log with -XX:+PrintAssembly is in attachment): 0xe774c15c: sub %ebx,%edx 0xe774c15e: sbb %eax,%ecx 0xe774c160: mov $0x0,%esi 0xe774c165: jge 0xe774c170 0xe774c16b: mov $0x8,%esi and the following cmp for the if will read modified value of the left operand and will produce unexpected result 0xe774c1a8: sub %ebx,%edx 0xe774c1aa: sbb %eax,%ecx 0xe774c1ac: jl 0xe774c150
25-09-2018