[Bug middle-end/50724] cmath's floating-point classification implementations inconsistent with math.h

[redi at gcc dot gnu.org]

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

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-10-17 21:21:45 UTC ---
(In reply to comment #28)
> 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.

Maybe you should consider that the maintainers have actually thought about it
and might know what they're talking about?  What is __isnan? Is that reliably
available on all supported platforms?  (Hint: no)  Is __builtin_isnan reliably
available? (Hint: yes)

Being patronising because you don't understand all the issues won't win you any
friends.

> 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.

If you want your code to conform to floating point standards THEN DON'T USE
-ffinite-math-only! It's there in the manual for all to see.

> 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.

That would be something for user code to do, not the library.
Feel free to do it in your code.

> 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.

Feel free to open a separate PR requesting a warning.

> I'll be pretty disappointed with gcc quality control if you really choose (E),
> but it's there.

I think we can live with your disappointment.

You are using a feature which is documented to alter behaviour for code using
NaNs, it clearly says "it can result in incorrect output for programs which
depend on an exact implementation of IEEE or ISO rules/specifications for math
functions".  If you don't like it, don't use the option.