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.
Comment #1 by clugdbug — 2013-03-25T09:01:10Z
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.
Comment #2 by bugzilla — 2013-03-25T14:52:53Z
Given the erratic and frankly bad support for signalling NaNs in the hardware, my inclination is to just drop support for them.
Comment #3 by andrej.mitrovich — 2013-03-25T15:00:33Z
Also relevant: Issue 6303
Comment #4 by clugdbug — 2013-07-26T07:47:40Z
*** Issue 6303 has been marked as a duplicate of this issue. ***
Comment #5 by cauterite — 2016-08-19T21:50:07Z
*** Issue 15316 has been marked as a duplicate of this issue. ***