This code should not raise the floating point 'invalid' flag. --- void foo() { double x; x = 2; real y; y = 7; float z; z = 4; } --- Here is the generated code for 32 bits: push EBP mov EBP,ESP sub ESP,018h fld qword ptr FLAT:.rodata[08h] // load SNAN - bad! fstp qword ptr -018h[EBP] fld qword ptr FLAT:.rodata[019h] fstp qword ptr -018h[EBP] fld tbyte ptr FLAT:.rodata[02Ah] fstp tbyte ptr -010h[EBP] mov word ptr -6[EBP],0 fld tbyte ptr FLAT:.rodata[045h] fstp tbyte ptr -010h[EBP] mov word ptr -6[EBP],0 fld float ptr FLAT:.rodata[060h] fstp float ptr -4[EBP] fld float ptr FLAT:.rodata[06Dh] fstp float ptr -4[EBP] leave ret The problem is, that the code first assigns SNAN to the variables *by loading them through the floating point unit*. This makes them trigger an INVALID exception. For this scheme to work, the floating point values would need to be loaded by integer operations.
An oddity about this, is that Intel processors will not raise the INVALID exception when initializing 80-bit reals. That is the one case where the scheme works correctly. It fails on AMD for all floating-point sizes. This is a barely-documented difference between Intel and AMD processors.
Given the erratic and frankly bad support for signalling NaNs in the hardware, my inclination is to just drop support for them.
Also relevant: Issue 6303
*** Issue 6303 has been marked as a duplicate of this issue. ***
*** Issue 15316 has been marked as a duplicate of this issue. ***
Just to reference the original post that seems to have started the SNaN usage. http://forum.dlang.org/post/gpsjfj$1678$1@digitalmars.com
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18547 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB