*** old/src/share/vm/compiler/compileBroker.cpp	Fri Aug  7 15:41:38 2015
--- new/src/share/vm/compiler/compileBroker.cpp	Fri Aug  7 15:41:37 2015

*** 1397,1406 ****
--- 1397,1428 ----
    }
  
    // do the compilation
    if (method->is_native()) {
      if (!PreferInterpreterNativeStubs || method->is_method_handle_intrinsic()) {
+       // The following native methods:
+       //
+       // java.lang.Float.intBitsToFloat
+       // java.lang.Float.floatToRawIntBits
+       // java.lang.Double.longBitsToDouble
+       // java.lang.Double.doubleToRawLongBits
+       //
+       // are called through the interpreter even if interpreter native stubs
+       // are not preferred (i.e., calling through adapter handlers is preferred).
+       // The reason is that on x86_32 signaling NaNs (sNaNs) are not preserved
+       // if the version of the methods from the native libraries is called.
+       // As the interpreter and the C2-intrinsified version of the methods preserves
+       // sNaNs, that would result in an inconsistent way of handling of sNaNs.
+       if ((UseSSE >= 1 &&
+           (method->intrinsic_id() == vmIntrinsics::_intBitsToFloat ||
+            method->intrinsic_id() == vmIntrinsics::_floatToRawIntBits)) ||
+           (UseSSE >= 2 &&
+            (method->intrinsic_id() == vmIntrinsics::_longBitsToDouble ||
+             method->intrinsic_id() == vmIntrinsics::_doubleToRawLongBits))) {
+         return NULL;
+       }
+ 
        // To properly handle the appendix argument for out-of-line calls we are using a small trampoline that
        // pops off the appendix argument and jumps to the target (see gen_special_dispatch in SharedRuntime).
        //
        // Since normal compiled-to-compiled calls are not able to handle such a thing we MUST generate an adapter
        // in this case.  If we can't generate one and use it we can not execute the out-of-line method handle calls.