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 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.) (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 |
|||
« Next Oldest | Next Newest »
|
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)