Nightly failed tests:

closed/compiler/6476804/Test.java
nsk/regression/b4335155
regression/other/argtest2
runtime/jbe/subcommon/subcommon05

It is regression after the push 6822110.

Copy and compile test/closed/compiler/6476804/Test.java

% bin/java -Xcomp Test
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/register_sparc.hpp:245
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/B/130204.ct232829/source/src/cpu/sparc/vm/register_sparc.hpp:245), pid=11781, tid=9
#  Error: assert(c < 64 && (c & 1) == 0,"bad double float register")
#
# JRE version: 7.0-b55
# Java VM: OpenJDK Server VM (16.0-b01-2009-04-22-130204.ct232829.6822110-jvmg compiled mode solaris-sparc )
Posted Date : 2009-04-23 18:00:11.0

N/A

Tom wrote this to the mailing list:

I looked into this a bit since it's the only thing blocking us pushing  
to hotspot/hotspot.  It's a problem with the support for $ 
$FloatRegister on sparc.  assembler_sparc does weird stuff with  
FloatRegister to deal with the encoding of the double registers above  
31 and that interacts badly with the way $$FloatRegister is  
implemented.  A loadConP has been assigned to D48, which would  
normally be constructed by the as_FloatRegister(48).  When it's  
actually used, it will be converted to a DoubleFloatRegister which  
will convert it into it's actual encoding as 17.  The adlc nows that  
D48 is actually encoded as 17 so it directly constructs a  
FloatRegister with an encoding of 17.  When we go to use it we die  
because double registers have even logical numbers.  So the quick fix  
is to use one of the other conversion idioms like  
as_DoubleFloatRegister($dst$$reg) to construct the register.  We'll  
need to address the implementation of $$FloatRegister separately.
Posted Date : 2009-04-24 11:36:05.0