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.