http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Ethan Tira-Thompson <ejtttje at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |
--- Comment #28 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-17
20:21:27 UTC ---
So then there are a variety of potential solutions to evaluate:
A) Don't use the builtin, go back to __isnan, perhaps only when -ff-m-o is in
effect. Paolo says this is bad, but it's not clear why. Seems like a decent
solution except for his apparent disapproval.
B) Change the builtin implementation, just for example with bitmasks:
inline bool isnan(float x) {
const int EXP = 0x7f800000;
const int FRAC = 0x007fffff;
const int y = *((int*)(&x));
return ((y&EXP)==EXP && (y&FRAC)!=0);
}
(this is what I'm using to reproduce isnan in my own code, maybe there are
better ways?)
But this may be a portability issue to support different float point standards,
right? That's just as much an argument to not have users trying to do this
themselves though.
C) This is getting out of my knowledge, but Paolo also suggested "splitting the
computation in parts via the new optimization attribute and pragma, keep the
is_nan & co classifications outside the -fast-math cores." That sounds elegant
and possibly straightforward if it's just a matter of adding an attribute.
D) Combination of A, B and/or C: add new 'safe' builtins, have cmath use them
when -ff-m-o is in effect, but otherwise use the presumably faster/more easily
optimized normal builtins when these optimizations won't change behavior.
E) Screw compatibility with older gcc or Apple's current gcc or other forks,
just update the documentation. Make it clear -ff-m-o includes both
classification and arithmetic functions, that this behavior is not portable or
consistent even within math.h vs. cmath, and let the users suck it up.
Generating warnings on calling the nan-generation functions like nan(char*) or
numeric_limits::quiet_NaN() and maybe the classification functions too (e.g.
"isX always evaluates to true/false") would be a plus.
I'll be pretty disappointed with gcc quality control if you really choose (E),
but it's there.
