JDK-8160425 : Vectorization with signalling NaN returns wrong result
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2016-06-28
  • Updated: 2017-08-07
  • Resolved: 2016-06-30
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.
9 b131Fixed
Related Reports
Relates :  
Attached TestNaNVector.java triggers the problem on 32-bit x86.

We vectorize the following loop:
for (int i = 0; i < 1024; ++i) {
  array[i] = (char)0xfff7;
The array store will be replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic this is a signalling NaN which may be converted to a quiet NaN when processed by the x87 FPU. If the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result.

The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions.
Fix verified by regression test.

ILW = incorrect code generated by C2, only with NaNs and -XX:-OptimizeFill, disable vectorization = HMM = P2

Fix: http://cr.openjdk.java.net/~thartmann/8159792/webrev.00/