JDK-4342148 : sun4m on Solaris 8: JCK vm tests fpm02501m1 and fpm02501m2 are both failing.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8,windows_nt,windows_2000
  • CPU: x86,sparc
  • Submitted: 2000-05-31
  • Updated: 2002-02-11
  • Resolved: 2002-02-01
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.
Other
1.4.0 merlinFixed
Related Reports
Duplicate :  
JDK-4342163 - sun4m/Sol_8: JCK vm tests fastore00101/dastore00101 fail when doing random r/w.
Duplicate :  
JDK-4342349 - sun4m: JCK lang tests fpl00506m1/fpl00506m2 fail in FP-wide/FP-strict expression
Duplicate :  
JDK-4335360 - java.lang.IllegalArgumentException: Illegal Load: 0.75 at java.util.Hashtable
Duplicate :  
JDK-4345368 - sun4m/2.8: JCK-lang failures with kest-sol-beta2 conv01512 and conv01506
Duplicate :  
JDK-4342444 - sun4m ONLY: 62 JCK-runtime-13rc2 api tests are failing in -client mode.
Description
The following JCK vm tests failed on this sun4m machine when checking proper format conversion of the returned double/float value:

javasoft.sqe.tests.vm.fp.fpm025.fpm02501m2.fpm02501m1
javasoft.sqe.tests.vm.fp.fpm025.fpm02501m2.fpm02501m2

jtg-s210:[133]% uname -a
SunOS jtg-s210 5.8 Generic_109291-02 sun4m sparc SUNW,SPARCstation-5
jtg-s210:[134]% psrinfo -v
Status of processor 0 as of: 05/30/00 18:11:45
  Processor has been on-line since 05/24/00 17:34:13.
  The sparc processor operates at 170 MHz,
	and has a sparc floating point processor.

To Reproduce:
=============
1. Extract fpm02501m1.ksh and fpm02501m2.ksh from attached files: fpm02501m1.jar/fpm02501m2.jar
2. Run fpm02501m1.ksh:

jtg-s210:[138]% fp02501m1.ksh
D.checkDefRetDefault(i) fails; value==NaN; lap # 5
D.checkDefRetDefault(i) fails; value==-Infinity; lap # 6
97

2. Run fpm02501m2.ksh:

jtg-s210:[168]% fpm02501m2.ksh
D.checkDefRetDefault(i) fails; value==NaN; lap # 5
D.checkDefRetDefault(i) fails; value==-Infinity; lap # 6
97

This problem is limited to sun4m machines ONLY.


vincent.lee@eng 2000-05-30


###@###.### 2002-01-21

I can reproduce it with JDK1.3.1_02 on Win NT 4.0 SP 5 on PC powered by Cyrix PR233 processor.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin FIXED IN: merlin INTEGRATED IN: merlin VERIFIED IN: merlin-fcs
14-06-2004
WORK AROUND -Xint
11-06-2004
EVALUATION exclude java/lang/Double isNaN exclude java/lang/Float isNaN and the test passes. Also, -XX:-CanonocalizeNodes also passes the test. canonicalized version of Test2::isNaN() __bci__use__tid____instr____________________________________ original code: . -1 0 10 if i8 == i9 then B0 else B1 canonicalized to: . -1 0 11 if d4 != d4 then B1 else B0 Bytecode and generated assembly for "Method boolean isNaN(float)": javac bytecode: 0 fload_0 1 fload_0 2 fcmpl 3 ifeq 10 6 iconst_1 7 goto 11 10 iconst_0 11 ireturn c1 generates for v9: 0xfa403410: sethi %hi(0xffffe000), %g3 0xfa403414: clr [ %sp + %g3 ] 0xfa403418: save %sp, -112, %sp 0xfa40341c: ld [ %fp + 0x5c ], %f0 0xfa403420: ld [ %fp + 0x60 ], %f1 0xfa403424: fcmpd %f0, %f0 0xfa403428: fbe,a,pn %fcc0, 0xfa403440 0xfa40342c: nop 0xfa403430: mov 1, %l0 0xfa403434: mov %l0, %o0 0xfa403438: b %icc, 0xfa403448 0xfa40343c: nop 0xfa403440: clr %l0 0xfa403444: mov %l0, %o0 0xfa403448: mov %o0, %i0 0xfa40344c: restore 0xfa403450: retl ; {return} 0xfa403454: nop 0xfa403458: nop 0xfa40345c: nop c1 generates for v8: 0xea0033d0: mov -4096 + %g3 0xea0033d4: clr [ %sp + %g3 ] 0xea0033d8: save %sp, -112, %sp 0xea0033dc: ld [ %fp + 0x5c ], %f0 0xea0033e0: ld [ %fp + 0x60 ], %f1 0xea0033e4: fcmpd %f0, %f0 0xea0033e8: fbe,a 0xea003400 0xea0033ec: nop 0xea0033f0: mov 1, %l0 0xea0033f4: mov %l0, %o0 0xea0033f8: b 0xea003408 0xea0033fc: nop 0xea003400: clr %l0 0xea003404: mov %l0, %o0 0xea003408: mov %o0, %i0 0xea00340c: restore 0xea003410: retl ; {return} /* * Below is the java source that reproduces the same bug. * javac Test2.java * java_g -Xcomp -Xcomp -XX:CompileOnly=Test2.isNaN Test2 */ public class Test2 { static boolean foo(double i) { return isNaN(i) || !isNaN(Double.NaN); } public static void main (String[] args) { /** * The first invocation of isNaN in this program generates the wrong result. * However the second invocation generates the correct result. */ System.out.println("isNaN(Double.Nan) = " + isNaN(Double.NaN)); System.out.println("isNaN(Double.Nan) = " + isNaN(Double.NaN)); } private static boolean isNaN (double v) { return (v != v); } } mohammad.gharahgouzloo@Eng 2000-06-02 for V8 must add a nop instruction between fcmp and fb srdjan.mitrovic@eng 2000-06-06 Committing to 1.4.1. ###@###.### 2002-01-23 I was curious about the sudden appearance of this bug so I did some investigation. I checked the Merlin C1 source code that handles floating- point branches and determined that this bug should still be fixed. I looked at this bug's change log and found that indeed it had been fixed and integrated way back in June, 2000. However, on 1/21/02 the bug's state was changed to "dispatched". I didn't believe the bug was somehow reintroduced so I ran the JCK tests both directly and under "runthese" using build rc-b91 on a SPARC V8 (sun4m) machine, jtg-s212. They both pass in several modes: java; java -Xcomp; and java_g -Xcomp -XX:CompileOnly=javasoft. This bug is still fixed and integrated. ###@###.### 2002-01-31
31-01-2002