Bug ID: JDK-8332827 [REDO] C2: crash in compiled code because of dependency on removed range check CastIIs

Versions (Unresolved/Resolved/Fixed)

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 24
24 masterUnresolved

$ java -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -XX:CompileCommand=dontinline,TestArrayAccessAboveRCAfterRCCastIIEliminated::notInlined TestArrayAccessAboveRCAfterRCCastIIEliminated
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f084cb56650, pid=1861816, tid=1861817
#
# JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.roland.jdk-jdk2)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.roland.jdk-jdk2, mixed mode, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# J 12 c2 TestArrayAccessAboveRCAfterRCCastIIEliminated.test(IIIZ)V (104 bytes) @ 0x00007f084cb56650 [0x00007f084cb56580+0x00000000000000d0]

A range check in the test case is optimized out thanks to a type narrowed down by a dominating range check. The load that depends on the removed range check is kept below the dominating range check by a range check CastII. The range check CastII is removed after loop opts are over. As a consequence, the load can float above the dominating range check.