Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4898278
Votes 1
Synopsis C1: Improper return of extra-precise fp values from native methods on windows
Category hotspot:compiler1
Reported Against tiger
Release Fixed 1.5(tiger-b30)
State 10-Fix Delivered, bug
Priority: 4-Low
Related Bugs 4851625 , 6213988
Submit Date 30-JUL-2003
Description
In the course of writing tests for the hyperbolic transcendental functions (4851625), I noticed some anomolies in the test output.  Namely a value returned from a Java method and a native floating-point method did not compare as equal but had the same represention when printed out as a long bit pattern (i.e. same result from Double.longBitsToDouble).  The values are no where near the overflow or underflow threshold so strictfp vs non-strictfp is not an issue.  The problem persists even when the method is declared strictfp.  Moreover, the results are written to local variables (which javac correctly preserves with dstore instructions) so both values must be members of the double value set.

I suspect C1 does not always clamp a long-double return value from a native method to double in some situations.  The problem does not occur when Java is invoked with -Xint, -server, -Xcomp -client, or -Xcomp -server.  The problem does not occur under Linux x86, at least not with the test program in question.

Tar ball of relevant files attached; run the HyperbolicsDiffFinderBug program.

The failure occured when the coding idiom

if( (local1=nativeSinh(d)) != (fdlibm1=StrictMath.sinh(d)) )

is used but not when

local1=nativeSinh(d);
fdlibm1=StrictMath.sinh(d);
if(loca1 != fdlibm1)

is used.
Work Around
N/A
Evaluation
The native wrapper needs to store double valeus down to the stack to round them.
  xxxxx@xxxxx   2003-10-23
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang