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- customer  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.


  xxxxx@xxxxx   2000-05-30


  xxxxx@xxxxx   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.

-Xint

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);
  }
}
  xxxxx@xxxxx   2000-06-02

for V8 must add a nop instruction between fcmp and fb
  xxxxx@xxxxx   2000-06-06

Committing to 1.4.1.

  xxxxx@xxxxx   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.
  xxxxx@xxxxx   2002-01-31

I do not understand the comments for this bug. I have an
application that uses java.util.HashSet; many users complain
on their Windows systems that they get the error message
"Illegal Load factor: 0.75   at java.util.HashMap.<init>". I
would like to tell these users, "install java x.y.z and the
problem will be gone". All bugs I could find that matched
mine were marked as duplicates of this one. Tell me, what
version of java exactly will fix this bug for Windows users?
Please use version numbers, not these "Merlin"/"Kestrel"
code names if possible, because I cannot fine the web page
that tells me which code names correspond to which version
numbers!!!

I have discovered a similar problem on a Dell Quad Xeon 
Server running JDK1.3.1_01. The error does not happen 
everytime I run the sample program above, but does happen 
approx. 25 times per 1000 runs. It is really causing havoc with 
my J2EE server. Does anyone have a fix for this version of the 
JDK or do I have to upgrade?

I got "java.lang.IllegalArgumentException: Illegal Load: 0.75" 
error using Oracle Universal Installer for 9.2 which include JRE 
1.3.1. I run Win2k with SP3 on Cyrus processor. Any 
workaround?