http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-15
08:50:56 UTC ---
(In reply to comment #11)
> Marc: is this code perusable? I'm curious because I expect either the
> calculations may generate NaN or not at all. If they might and you even have
> test cases to handle it, then I'm surprised you would ever want to support
> running with -ff-m-o. Conversely if you knew the code doesn't generate the
> nonfinite values, then you don't need the classifications in the first
> place...?
>
> I'm guessing (and apologies if this is inaccurate) that this might boil down
> to
> saying that you want to interpret an end user setting -ff-m-o as an
> opportunity
> to skip validating their input or skip doing assertions during its processing,
> which could be a reasonable thing to do, but that's a choice I'd rather leave
> to individual developers, e.g. can also wrap code with #if
> __FINITE_MATH_ONLY__==0 or such...
>
> Or in other words, it's only a missed optimization if you wind up with
> classification calls, whereas it's a full-fledged execution error when NaN
> gets
> past validation.
You can switch between explicit checking and trapping for example, by
switching between -ffinite-math-only and -fno-trapping-math.
Note that in general it is impossible to decide whether an argument of
isnan() is from user input or previous computation. Which means that
making isnan() special for -ffinite-math-only makes as much sense as
special-casing any math library function (that may also take user input).
This has been discussed to death already, and the present behavior is how
GCC behaved since ever. It's not a bug. The documentation states
"Allow optimizations for floating-point arithmetic that assume
that arguments and results are not NaNs or +-Infs."
it is clear that isnan(x) may then be optimized assuming that x is
not NaN.
