This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]