[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

["iano at apple dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #11 from iano at apple dot com  2006-08-22 01:45 -------
About the manual wrongheadedness:

The major argument that I have heard from members of the GCC community (here
and elsewhere) against isnan() in its various forms correctly detecting NaN
when various hacky math flags are turned on, is that the hacky math flags are
defined to preclude the presence of NaNs.  The argument goes that the user
actually asked for the possibility all NaNs to be ignored! 

This is circular reasoning. The fact of the matter is that GCC defines all the
meanings of the flags. You can't claim the user wanted isnan(NaN) to return 0,
because you provided him with no opportunity to say otherwise.  I contend that
given the choice, the user will want isnan(NaN) to correctly  detect NaN's even
if the rest of the application does not, because when one is walking on a tight
rope, it is good to have a safety net in case something goes wrong.  You can't
deal with NaNs in special case code unless you have a way to find them. What
you've given him is a choice between unavoidably wrong results, or "poor
speed".

If you can find a set of flags that would allow the user to do speed enhancing
things like assume that make the assumption that x-x is always 0, while at the
same time have __builtin_isnan(NaN) still work in the same compilation unit --
we want these things to inline for speed! -- then I will be happy to concede
this point. Otherwise, I assert that the overly simple interpretation of these
flags currently in practice does not serve the developer's needs. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796