Post Reply 
Be quiet, NaN
10-15-2020, 12:55 AM
Post: #4
RE: Be quiet, NaN
(10-14-2020 09:22 PM)mpark Wrote:  Wow, interesting! Thanks, Albert.

This is one nasty bug Big Grin

The fix is ugly, and not worth the hassle. I am quoting from Geoff Chappell post (for float)
Signaling NaN (float, double) becomes quiet NaN when returned from function (both x86 and x64)

Quote:Compiled for 32-bit Windows, GenerateNaN will return your NaN through the floating-point register ST(0). This loads your pattern into the FPU. If exceptions - the signal of your "signaling NaN' - are masked, then your NaN is silently converted from 0x7F800001 to 0x7FC00001. I don't think there's anything you can do about this except to unmask the exception and get the signal. It's the FPU architecture. But if you do want the signal, the CRT has the _controlfp_s routine, which may help. (I confess to having never ever had any real-world use for this.)

Compiled for 64-bit Windows, the pattern is returned through XMM0 without being an FPU operand.
So you get no conversion.

(10-14-2020 10:46 PM)cruff Wrote:  Was your runtime support perhaps compiled with '-fno-signaling-nans'?

Yes, I think that was gcc default setting.
https://gcc.gnu.org/onlinedocs/gcc/Optim...ze-Options
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
Be quiet, NaN - Albert Chan - 10-14-2020, 04:15 PM
RE: Be quiet, NaN - mpark - 10-14-2020, 09:22 PM
RE: Be quiet, NaN - Albert Chan - 10-15-2020 12:55 AM
RE: Be quiet, NaN - cruff - 10-14-2020, 10:46 PM



User(s) browsing this thread: 1 Guest(s)