http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Ethan Tira-Thompson <ejtttje at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
--- Comment #2 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-14
14:27:13 UTC ---
Well, that's not actually true: -fno-finite-math is telling the compiler to
assume finite results during computation, but that doesn't mean there are "no
NaNs". For example, I need isnan/isfinite to validate my users' input before I
can ensure that invariant afterward. Clearly the bit pattern still exists in
the universe.
I'd also argue classification functions are not "arithmetic" and thus not
covered by -fno-finite-math ("Allow optimizations for floating-point
arithmetic")
Finally, I think you're being quick to brush off the consistency issue, both
with earlier gcc versions and with math.h. I find it quite disconcerting that
isnan behavior changes between the two headers.
Is your concern that __builtin_isnan is called internally during fp
computations and we need to optimize that away in order to provide the speed
advantages requested by -fno-finite-math? In that case, I propose cmath should
be updated to check __FINITE_MATH_ONLY__ in its user-facing isnan and fall back
to a safe method like math.h is currently using (apparently __isnan/__isnanf).
Otherwise, as I established above, I don't think it's safe to 'optimize' away
the floating point classification functions: the first issue above is code
safety/security, the second is pedantic regarding documentation, and the third
is a consistency issue.
Thanks!
