United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6451816 : Remainder operation seems to cause an exception in 1.4.2_12

Details
Type:
Bug
Submit Date:
2006-07-24
Status:
Resolved
Updated Date:
2014-02-27
Project Name:
JDK
Resolved Date:
2006-11-20
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_12
Fixed Versions:
1.4.2_14 (b01)

Related Reports

Sub Tasks

Description
The attached test program sometimes outputs an exception.

CONFIGURATION :
 - JRE : 1.4.2_12 for sparc edition
 - OS : Solaris 10(SunOS chive 5.10 Generic sun4u sparc SUNW,Ultra-5_10)

REPRODUCE :
 1) Run the attached  run.sh in 1.4.2_XX
 
EXPECTED :
 chive[22]% run.sh
1 java -server HashCodeTest
2 java -server HashCodeTest
3 java -server HashCodeTest
4 java -server HashCodeTest
5 java -server HashCodeTest
6 java -server HashCodeTest
7java -server HashCodeTest
8 java -server HashCodeTest
.........

ACTUAL : 
chive[25]% run.sh
1 java -server HashCodeTest
Exception in thread "main" java.lang.RuntimeException: -1077554975%2047=1178
        at HashCodeTest.run(HashCodeTest.java:21)
        at HashCodeTest.main(HashCodeTest.java:6)
2 java -server HashCodeTest
Exception in thread "main" java.lang.RuntimeException: -1077554975%2047=1178
        at HashCodeTest.run(HashCodeTest.java:21)
        at HashCodeTest.main(HashCodeTest.java:6)
3 java -server HashCodeTest
Exception in thread "main" java.lang.RuntimeException: -1077554975%2047=1178
        at HashCodeTest.run(HashCodeTest.java:21)
        at HashCodeTest.main(HashCodeTest.java:6)
4 java -server HashCodeTest
Exception in thread "main" java.lang.RuntimeException: -1077554975%2047=1178
        at HashCodeTest.run(HashCodeTest.java:21)
        at HashCodeTest.main(HashCodeTest.java:6)
.......


NOTE :
 - This problem does not occur in 1.3.1, 1.4.1 and 5.0
 - This problem does not occur in -client and -Xint

-----

                                    

Comments
EVALUATION

I have found the fix for this problem. Here are the source changes that fix this issue:

------- sparc.ad -------
379a380,390
> // Class for all long registers, except the G3 register.  This is used for
> // encodings which use G3 register as temp.
> reg_class noG3_long_reg(        R_G1H,R_G1,                         R_G4H,R_G4, R_G5H,R_G5
>                    ,R_O0H,R_O0, R_O1H,R_O1, R_O2H,R_O2, R_O3H,R_O3, R_O4H,R_O4, R_O5H,R_O5
> #ifdef _LP64
> // 64-bit, longs in 1 register: use all 64-bit integer registers
> // 32-bit, longs in 1 register: cannot use I's and L's.  Restrict to O's and G's.
>                    ,R_L0H,R_L0, R_L1H,R_L1, R_L2H,R_L2, R_L3H,R_L3, R_L4H,R_L4, R_L5H,R_L5, R_L6H,R_L6, R_L7H,R_L7
>                    ,R_I0H,R_I0, R_I1H,R_I1, R_I2H,R_I2, R_I3H,R_I3, R_I4H,R_I4, R_I5H,R_I5
> #endif // _LP64
>                   );
3773a3785,3794
> operand noG3_iRegI_64bit_safe() %{
>   constraint(ALLOC_IN_RC(noG3_long_reg));
>
>   match(RegI);
>   match(notemp_iRegI);
>
>   format %{ %}
>   interface(REG_INTER);
> %}
>
6668c6689
< instruct modI_reg_reg(iRegI dst, notemp_iRegI src1, notemp_iRegI src2, g3RegP temp, flagsReg ccr ) %{
---
> instruct modI_reg_reg(iRegI dst, noG3_iRegI_64bit_safe src1, noG3_iRegI_64bit_safe src2, g3RegP temp, flagsReg ccr ) %{
6678c6699
< instruct modI_reg_imm13(iRegI dst, notemp_iRegI src1, immI13 src2, g3RegP temp, flagsReg ccr ) %{
---
> instruct modI_reg_imm13(iRegI dst, noG3_iRegI_64bit_safe src1, immI13 src2, g3RegP temp, flagsReg ccr ) %{


After some more testing, I will send the binary to customer for fix verification.
                                     
2006-07-27



Hardware and Software, Engineered to Work Together