This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 15 Oct 2011 08:50:56 +0000
- Subject: [Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
- Auto-submitted: auto-generated
- References: <bug-50724-4@http.gcc.gnu.org/bugzilla/>
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.