C2 is incorrectly doing unsigned comparisons against -1.

Attached is a sample Java source file and the corresponding class file (I have attached the class file as well in case the bug is dependant on the version javac used to compile the Java source).

Also attached is a CompileCommandFile 'compile_files'

If I then run this as following with a release build of the jdk9 tip as follows

/work/images/jdk-release/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileCommandFile=compile_files TestMultiplyToLen

I get the following

Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.math.BigInteger.<init>(BigInteger.java:385)
at java.math.BigInteger.<init>(BigInteger.java:422)
at java.math.BigInteger.<init>(BigInteger.java:679)
at TestMultiplyToLen.main(TestMultiplyToLen.java:91)

The test should just print 'Success'

If I take a look at the assembly output as follows

/work/images/jdk-release/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileCommandFile=compile_files -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly TestMultiplyToLen

I see the following in the asm output (I have attached the assembler output in the file asm.out).

  0x00007f20b907aed6: cmp $0xffffffff,%r10d
  0x00007f20b907aeda: jbe 0x00007f20b907af46 ;*if_icmpge
                                                ; - java.math.BigInteger::<init>@41 (line 381)
                                                ; - java.math.BigInteger::<init>@6 (line 422)
                                                ; - java.math.BigInteger::<init>@7 (line 679)

So, here it is doing an unsigned comparison again -1 (0xffffffff). This results in the exception always being thrown.

If I then build a slowdebug version and run it as follows

/work/images/jdk-slowdebug/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileCommandFile=compile_files -XX:+PrintCompilation -XX:+PrintIdeal -XX:+PrintOptoAssembly -XX:+PrintAssembly TestMultiplyToLen

I see the following in the ideal graph (attached as file slowdebug.out)

 309 CmpU === _ 306 305 [[ 310 ]]
 305 ConI === 0 [[ 306 309 ]] #int:-1
 306 AddI === _ 66 305 [[ 309 ]] !orig=[304]
 66 LoadRange === 55 7 65 [[ 162 306 85 ]] @bottom[int:>=0]+12 * [narrow], idx=4; #int:>=0 !jvms: BigInteger::<init> @ bci:5 BigInteger::<init> @ bci:7

So, here we can see that it is doing an unsigned comparison (node 309) against -1 (node 305)

This is also reflected in the opto assembly (again in the attached file slowdebug.out)

056 cmpl R10, #-1 # unsigned
05a jbe,u B13 P=0.000001 C=-1.000000

This bug also occurs in the aarch64 port. In fact I found it first in the aarch64 port except on the aarch64 port it is not necessary to do the -Xcomp -XX:CompileCommandFIle=... to force the bug, it just happens if you simply do -XX:-TieredCompilation

The bug seems to have been introduced in the following changeset

# HG changeset patch
# User roland
# Date 1426583191 -3600
# Tue Mar 17 10:06:31 2015 +0100
# Node ID f5fae6f265e2c403cc51046050a4702a33625038
# Parent dbd15e131b5fc6e319e71c77c14d45eae623ed92
8073480: C2 should optimize explicit range checks
Summary: explicit range checks should be recognized by C2
Reviewed-by: kvn, vlivanov

If I back out this single changeset the bug goes away.