-
Bug
-
Resolution: Unresolved
-
P4
-
26
-
other
There is an issue with fix against JDK-8356760 on windows-x64 related to following line
long mask = (-1ULL >> (64 - vlen));
-1ULL is unsigned "long long (64-bit)" and the shift produces a 64-bit unsigned value which is then assigned to "long".
On Linux-x64/macOS-x64(LP64 platforms), "long" is 64-bit but on windows-x64 (LLP64 platform), the "long" type is 32 bits, while "long long" is 64 bits. So execution of "-1ULL >> (64 - vlen)", the right-hand side of the assignment is an unsigned "long long" and the result of this 64-bit operation , is then assigned to the variable "mask" of type "long" which is a 32-bit on windows-x64. This means on windows-x64 when this 64-bit result is assigned to the 32-bit long variable, the value is truncated. The upper 32 bits of the 64-bit value are discarded which leads to precision loss.
long mask = (-1ULL >> (64 - vlen));
-1ULL is unsigned "long long (64-bit)" and the shift produces a 64-bit unsigned value which is then assigned to "long".
On Linux-x64/macOS-x64(LP64 platforms), "long" is 64-bit but on windows-x64 (LLP64 platform), the "long" type is 32 bits, while "long long" is 64 bits. So execution of "-1ULL >> (64 - vlen)", the right-hand side of the assignment is an unsigned "long long" and the result of this 64-bit operation , is then assigned to the variable "mask" of type "long" which is a 32-bit on windows-x64. This means on windows-x64 when this 64-bit result is assigned to the 32-bit long variable, the value is truncated. The upper 32 bits of the 64-bit value are discarded which leads to precision loss.
- caused by
-
JDK-8356760 VectorAPI: Optimize VectorMask.fromLong for all-true/all-false cases
-
- Resolved
-