Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8366845

C2 SuperWord: wrong VectorCast after VectorReinterpret with swapped src/dst type

XMLWordPrintable

    • master
    • x86_64

      I have seen 3 manifestations of this bug:

      1.
      # Internal Error (.../src/hotspot/cpu/x86/x86.ad:7640), pid=84140, tid=28419
      # assert(UseAVX > 2 && VM_Version::supports_avx512dq()) failed: required

      2.
      # Internal Error (.../src/hotspot/share/opto/vectornode.cpp:1601), pid=4022154, tid=4022168
      # Error: assert(bt == T_FLOAT) failed

      3. Wrong result
      When the feature was available but we used the wrong CastVector

      It seems that JDK-8346236 introduced reinterpret nodes to SuperWord:

        } else if (VectorNode::is_reinterpret_opcode(opc)) {
          assert(first->req() == 2 && req() == 2, "only one input expected");
          const TypeVect* vt = TypeVect::make(bt, vlen);
          vn = new VectorReinterpretNode(in1, vt, in1->bottom_type()->is_vect());

      Sandly, the src and dst type are swapped. For JDK25 JDK-8346236 this had no bad effect yet, since we only cast between HF and short, which are both based on short.

      But with JDK-8329077 we can now do reinterpret between I/F and between D/L. Here swapping has an effect, especially if it is followed by a cast:
      The cast deterines its input type from the output type of the input node. If that was a reinterpret node with the wrong output type, we would get a cast with the wrong src type. We might do a double -> int cast instead of a long -> int cast. That leads to all sorts of issues.

      The fuzzer test was only just recently added with JDK-8324751. It uses MemorySegment, where unaligned float/double access gets handled with long/int memory access and then reinterpret (eg MoveI2F). But I was able to find examples that just work with Float.intBitsToFloat etc.

      -------------------------- ORIGINAL REPORT ----------------------------

      Test: compiler/loopopts/superword/TestAliasingFuzzer.java#vanilla

      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S168313/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2e223971-59eb-4ff2-b885-5f2f25e941b2/runs/a784d7c0-ede9-4ff5-af8c-35fe679d2c2b/workspace/open/src/hotspot/cpu/x86/x86.ad:7640), pid=84140, tid=28419
      # assert(UseAVX > 2 && VM_Version::supports_avx512dq()) failed: required
      #
      # JRE version: Java(TM) SE Runtime Environment (26.0+14) (fastdebug build 26-ea+14-1424)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-ea+14-1424, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
      # Core dump will be written. Default location: core.84140
      #
      # If you would like to submit a bug report, please visit:
      # https://bugreport.java.com/bugreport/crash.jsp
      #

      --------------- S U M M A R Y ------------

      Command Line: -Djava.library.path=/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-26+14-1424/macosx-x64-debug.test/hotspot/jtreg/native -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk/24/36/bundles/macos-x64/jdk-24_macos-x64_bin.tar.gz/jdk-24.jdk/Contents/Home -Djava.io.tmpdir=/System/Volumes/Data/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S168299/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ffeecce3-f54d-43db-867b-fee88f68d77e/runs/699d015b-1320-4cf5-8184-c78c7476666f/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_compiler_3/tmp -Dir.framework.server.port=58166 -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:CompilerDirectivesFile=test-vm-compile-commands-pid-84137.log -XX:CompilerDirectivesLimit=101 -XX:-OmitStackTraceInFastThrow -DShouldDoIRVerification=true -XX:-BackgroundCompilation -XX:CompileCommand=quiet compiler.lib.ir_framework.test.TestVM compiler.loopopts.superword.templated.AliasingFuzzer

      Host: "Macmini8,1" x86_64 3200 MHz, 12 cores, 32G, Darwin 22.6.0, macOS 13.6.3 (22G436)
      Time: Wed Sep 3 20:06:14 2025 GMT elapsed time: 26.874742 seconds (0d 0h 0m 26s)

      --------------- T H R E A D ---------------

      Current thread (0x00007fafa481b210): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=28419, stack(0x000070000ee3e000,0x000070000ef3e000) (1024K)]


      Current CompileTask:
      C2:26874 1248 b 4 compiler.loopopts.superword.templated.AliasingFuzzer::test_989 (133 bytes)

      Stack: [0x000070000ee3e000,0x000070000ef3e000], sp=0x000070000ef3a870, free space=1010k
      Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.dylib+0x1423474] VMError::report(outputStream*, bool)+0x1f14 (x86.ad:7640)
      V [libjvm.dylib+0x142742b] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x60b
      V [libjvm.dylib+0x72d188] report_vm_error(char const*, int, char const*, char const*, ...)+0xd8
      V [libjvm.dylib+0xbd038] vcastLtoX_evexNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const+0x7d8
      V [libjvm.dylib+0x10945e3] PhaseOutput::scratch_emit_size(Node const*)+0x2a3
      V [libjvm.dylib+0x1086d25] PhaseOutput::shorten_branches(unsigned int*)+0x445
      V [libjvm.dylib+0x10863ad] PhaseOutput::Output()+0x7ad
      V [libjvm.dylib+0x677e38] Compile::Code_Gen()+0x958
      V [libjvm.dylib+0x674b4a] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1d1a
      V [libjvm.dylib+0x52e5d0] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x200
      V [libjvm.dylib+0x6974b2] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc42
      V [libjvm.dylib+0x696447] CompileBroker::compiler_thread_loop()+0x3f7
      V [libjvm.dylib+0xab4c98] JavaThread::thread_main_inner()+0x1b8
      V [libjvm.dylib+0x136150c] Thread::call_run()+0xbc
      V [libjvm.dylib+0x1075c57] thread_native_entry(Thread*)+0x137
      C [libsystem_pthread.dylib+0x61d3] _pthread_start+0x7d
      C [libsystem_pthread.dylib+0x1bd3] thread_start+0xf
      Lock stack of current Java thread (top to bottom):

        1. Test_8366845.java
          12 kB
        2. Test1.java
          2 kB
        3. Test2.java
          2 kB
        4. Test3.java
          2 kB

            epeter Emanuel Peter
            dholmes David Holmes
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: