JDK-4984407 : StrictMath.atan2 and StrictMath.pow return incorrect values for AMD64 machine
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.5_b12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2004-01-28
  • Updated: 2004-05-04
  • Resolved: 2004-04-26
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
5.0 b49Fixed
Related Reports
Relates :  
Description
StrictMath.atan2 and StrictMath.pow methods returns incorrect values on AMD64 machine under Windows 2003.

To reproduce a failure please run the follwing test:
------------------test.java-------------------------
public class test {
        public static void main(String[] argv) {
                long atan_res = test_atan2(0xc008000000000000L, 0x7ff0000000000000L);
                if( atan_res != 0x8000000000000000L) {
                        System.out.println("atan:" + Long.toHexString(atan_res));
                }
                long pow1_res = test_pow(0x8000000000000000L, 0x4008000000000000L);
                if( pow1_res != 0x8000000000000000L) {
                        System.out.println("pow (1):" + Long.toHexString(pow1_res));
                }

                long pow2_res = test_pow(0xfff0000000000000L, 0xc008000000000000L);
                if( pow2_res != 0x8000000000000000L) {
                        System.out.println("pow (2):" + Long.toHexString(pow2_res));
                }

                System.out.println("Finished!");
        }

        static long test_atan2(long arg1, long arg2) {
                double darg1 = Double.longBitsToDouble(arg1);
                double darg2 = Double.longBitsToDouble(arg2);
                return Double.doubleToLongBits(StrictMath.atan2(darg1,darg2));
        }

        static long test_pow(long arg1, long arg2) {
                double darg1 = Double.longBitsToDouble(arg1);
                double darg2 = Double.longBitsToDouble(arg2);
                return Double.doubleToLongBits(StrictMath.pow(darg1,darg2));
        }
}
-----------------------------------------------
compile it:
$javac -d . test.java

and run:
$ N:\koori.sfbay\onestop\jdk\1.5.0\promoted\beta\b32c\binaries\windows-amd64\bin\java.exe -cp . test
atan:0
pow (1):0
pow (2):0
Finished! 

Note that if you are running this test on 32-bit vm machine, the test is passed:
N:\koori.sfbay\onestop\jdk\1.5.0\promoted\beta\b32c\binaries\windows-i586\bin\java.exe -cp . test
Finished!

Also if you are running this test under linux-amd64 then the test is passed:
$ /net/koori.sfbay/onestop/jdk/1.5.0/promoted/beta/b32c/binaries/linux-amd64/bin/java -cp . test
Finished!

###@###.### 2004-01-30

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b49 tiger-beta2 VERIFIED IN: tiger-beta2
14-06-2004

SUGGESTED FIX src/share/native/java/lang/fdlibm/src>sccs sccsdiff -r1.8 -r1.9 e_pow.c ------- e_pow.c ------- 169c169 < z = -z; /* (x<0)**odd = -(|x|**odd) */ --- > z = -1.0*z; /* (x<0)**odd = -(|x|**odd) */ src/share/native/java/lang/fdlibm/src>sccs sccsdiff -r1.9 -r1.10 e_atan2.c ------- e_atan2.c ------- 96c96 < case 1: return -zero ; /* atan(-...,+INF) */ --- > case 1: return -1.0*zero ; /* atan(-...,+INF) */ ###@###.### 2004-04-16
16-04-2004

EVALUATION Most likely a problem compiling the native fdlibm code. ###@###.### 2004-01-30 The obvious solution of tweaking the compilation flags has not worked. Instead of the failure occuring for "random" arguments, the failure is on "special" arguments and particular code paths. The integer portion of the computation may be getting mangled. Continuing investigation. ###@###.### 2004-03-01 Problem seems to be a code gen bug in the windows amd64 C compiler; see comments for details. ###@###.### 2004-03-02
01-03-2004