src/share/vm/runtime/sharedRuntimeTrig.cpp

*** 24,72 ****
  
  #include "precompiled.hpp"
  #include "prims/jni.h"
  #include "runtime/interfaceSupport.hpp"
  #include "runtime/sharedRuntime.hpp"
  
  // This file contains copies of the fdlibm routines used by
  // StrictMath. It turns out that it is almost always required to use
  // these runtime routines; the Intel CPU doesn't meet the Java
  // specification for sin/cos outside a certain limited argument range,
  // and the SPARC CPU doesn't appear to have sin/cos instructions. It
  // also turns out that avoiding the indirect call through function
  // pointer out to libjava.so in SharedRuntime speeds these routines up
  // by roughly 15% on both Win32/x86 and Solaris/SPARC.
  
- // Enabling optimizations in this file causes incorrect code to be
- // generated; can not figure out how to turn down optimization for one
- // file in the IDE on Windows
- #ifdef WIN32
- # pragma optimize ( "", off )
- #endif
- 
- /* The above workaround now causes more problems with the latest MS compiler.
-  * Visual Studio 2010's /GS option tries to guard against buffer overruns.
-  * /GS is on by default if you specify optimizations, which we do globally
-  * via /W3 /O2. However the above selective turning off of optimizations means
-  * that /GS issues a warning "4748". And since we treat warnings as errors (/WX)
-  * then the compilation fails. There are several possible solutions
-  * (1) Remove that pragma above as obsolete with VS2010 - requires testing.
-  * (2) Stop treating warnings as errors - would be a backward step
-  * (3) Disable /GS - may help performance but you lose the security checks
-  * (4) Disable the warning with "#pragma warning( disable : 4748 )"
-  * (5) Disable planting the code with  __declspec(safebuffers)
-  * I've opted for (5) although we should investigate the local performance
-  * benefits of (1) and global performance benefit of (3).
-  */
- #if defined(WIN32) && (defined(_MSC_VER) && (_MSC_VER >= 1600))
- #define SAFEBUF __declspec(safebuffers)
- #else
- #define SAFEBUF
- #endif
- 
- #include "runtime/sharedRuntimeMath.hpp"
- 
  /*
   * __kernel_rem_pio2(x,y,e0,nx,prec,ipio2)
   * double x[],y[]; int e0,nx,prec; int ipio2[];
   *
   * __kernel_rem_pio2 return the last three digits of N with
--- 24,44 ----
  
  #include "precompiled.hpp"
  #include "prims/jni.h"
  #include "runtime/interfaceSupport.hpp"
  #include "runtime/sharedRuntime.hpp"
+ #include "runtime/sharedRuntimeMath.hpp"
  
  // This file contains copies of the fdlibm routines used by
  // StrictMath. It turns out that it is almost always required to use
  // these runtime routines; the Intel CPU doesn't meet the Java
  // specification for sin/cos outside a certain limited argument range,
  // and the SPARC CPU doesn't appear to have sin/cos instructions. It
  // also turns out that avoiding the indirect call through function
  // pointer out to libjava.so in SharedRuntime speeds these routines up
  // by roughly 15% on both Win32/x86 and Solaris/SPARC.
  
  /*
   * __kernel_rem_pio2(x,y,e0,nx,prec,ipio2)
   * double x[],y[]; int e0,nx,prec; int ipio2[];
   *
   * __kernel_rem_pio2 return the last three digits of N with
*** 199,209 ****
  zeroB   = 0.0,
  one     = 1.0,
  two24B  = 1.67772160000000000000e+07, /* 0x41700000, 0x00000000 */
  twon24  = 5.96046447753906250000e-08; /* 0x3E700000, 0x00000000 */
  
! static SAFEBUF int __kernel_rem_pio2(double *x, double *y, int e0, int nx, int prec, const int *ipio2) {
    int jz,jx,jv,jp,jk,carry,n,iq[20],i,j,k,m,q0,ih;
    double z,fw,f[20],fq[20],q[20];
  
    /* initialize jk*/
    jk = init_jk[prec];
--- 171,181 ----
  zeroB   = 0.0,
  one     = 1.0,
  two24B  = 1.67772160000000000000e+07, /* 0x41700000, 0x00000000 */
  twon24  = 5.96046447753906250000e-08; /* 0x3E700000, 0x00000000 */
  
! static int __kernel_rem_pio2(double *x, double *y, int e0, int nx, int prec, const int *ipio2) {
    int jz,jx,jv,jp,jk,carry,n,iq[20],i,j,k,m,q0,ih;
    double z,fw,f[20],fq[20],q[20];
  
    /* initialize jk*/
    jk = init_jk[prec];
*** 415,425 ****
  pio2_2  =  6.07710050630396597660e-11, /* 0x3DD0B461, 0x1A600000 */
  pio2_2t =  2.02226624879595063154e-21, /* 0x3BA3198A, 0x2E037073 */
  pio2_3  =  2.02226624871116645580e-21, /* 0x3BA3198A, 0x2E000000 */
  pio2_3t =  8.47842766036889956997e-32; /* 0x397B839A, 0x252049C1 */
  
! static SAFEBUF int __ieee754_rem_pio2(double x, double *y) {
    double z,w,t,r,fn;
    double tx[3];
    int e0,i,j,nx,n,ix,hx,i0;
  
    i0 = ((*(int*)&two24A)>>30)^1;        /* high word index */
--- 387,397 ----
  pio2_2  =  6.07710050630396597660e-11, /* 0x3DD0B461, 0x1A600000 */
  pio2_2t =  2.02226624879595063154e-21, /* 0x3BA3198A, 0x2E037073 */
  pio2_3  =  2.02226624871116645580e-21, /* 0x3BA3198A, 0x2E000000 */
  pio2_3t =  8.47842766036889956997e-32; /* 0x397B839A, 0x252049C1 */
  
! static int __ieee754_rem_pio2(double x, double *y) {
    double z,w,t,r,fn;
    double tx[3];
    int e0,i,j,nx,n,ix,hx,i0;
  
    i0 = ((*(int*)&two24A)>>30)^1;        /* high word index */
*** 914,923 ****
      n = __ieee754_rem_pio2(x,y);
      return __kernel_tan(y[0],y[1],1-((n&1)<<1)); /*   1 -- n even
                                                       -1 -- n odd */
    }
  JRT_END
- 
- 
- #ifdef WIN32
- # pragma optimize ( "", on )
- #endif
--- 886,890 ----