On Wed, 22 Feb 2023 04:03:02 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Change the java/lang/float.java and the corresponding shared runtime >> constant expression evaluation to generate QNaN. >> The HW instructions generate QNaNs and not SNaNs for floating point >> instructions. This happens across double, float, and float16 data types. The >> most significant bit of mantissa is set to 1 for QNaNs. > > I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have > three mechanisms for implementing this functionality: > > 1. The interpreted Java code > 2. The compiled non-intrinisc sharedRuntime code > 3. The compiler intrinsic that uses a hardware instruction. > > Unless the hardware instructions for all relevant CPUs behave exactly the > same, then I don't see how we can have parity of behaviour across these three > mechanisms. > > The observed behaviour may be surprising but it seems not to be a bug. And is > this even a real concern - would real programs actually need to peek at the > raw bits and so see the difference, or does it suffice to handle Nan's > opaquely? @dholmes-ora @jddarcy @TobiHartmann @vnkozlov From @dean-long 's comment in the JBS entry, he sees the same result on AARCH64 and Intel, i.e. the output has the QNaN bit set. Please let me know if we want to proceed with this PR or if it would be good to withdraw this. I am open to either suggestion. Please advice. ------------- PR: https://git.openjdk.org/jdk/pull/12704
