From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17574 invoked by alias); 17 Oct 2011 07:14:26 -0000 Received: (qmail 17564 invoked by uid 22791); 17 Oct 2011 07:14:25 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 07:14:11 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/50724] isnan broken by -ffinite-math-only in g++ Date: Mon, 17 Oct 2011 07:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Resolution Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg01581.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Richard Guenther changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |DUPLICATE --- Comment #18 from Richard Guenther 2011-10-17 07:12:38 UTC --- (In reply to comment #17) > Richard said: > > math.h is not part of GCC > > But the point is there is value in consistency between math.h and cmath > regardless of who owns math.h. I'm asserting that this value is greater than > that gained by 'optimizing away' the classification functions in cmath. > Inconsistency leads to confused users and therefore bugs, missed optimization > is only going to cause slower code. You get the same inconsistency if math.h implements isnan as #define isnan(x) (!((x)==(x))) which is a valid implementation. That would be optimized with your suggested -ffinite-math-only implementation, but not when the library implements isnan as #define isnan(x) __builtin_isnan(x) So what's your point again? > I get that you want to make the most of > -ffast-math, and if it were a big speedup it could be worthwhile, but it seems > reasonable that if someone is serious about optimizing away their > classification sanity checks in a release build, they would be better served by > using assert() or an #ifdef instead of relying of the vagaries of -ffast-math > for this purpose. > > > The only way out I see that not breaks other users uses would be a new > > flag, like -fpreserve-ieee-fp-classification that, ontop of -ffinite-math-only, > > I'm not opposed to a new flag, but I'd suggest the reverse semantics. > Disabling classification is an extra degree of non-compliance beyond ignoring > non-finite math operations. I'd rather users add flags to progressively become > less compliant, rather than add a flag to get some compliance back. The point is backward-compatible behavior of -ffast-math. We can't and should not break this without a very very very good reason. Which this isn't. > But to rewind a second, I want to address the "breaks other users" comment... > here is the status AFAIK: > 1) Older versions (4.1, 4.2) of gcc did not do this optimization of > classification functions. Thus, "legacy" code expects classification to work > even in the face of -ffast-math, which was changed circa 4.3/4.4 Sure they did. > 2) Removing classification 'breaks' code because it fundamentally strips > execution paths which may otherwise be used. > 3) Leaving classification in could be considered a missed optimization, but is > at worst only a performance penalty, not a change in execution values. > 4) Personal conjecture: I doubt the classification routines are a performance > bottleneck in the areas where -ff-m-o is being applied, so (3) is pretty > minimal. And I seriously doubt anyone is relying on the removal of > classification in a code-correctness context, that doesn't make any sense. I have written code that you can switch between using FP exceptions and explicit checks at certain points. I expect the checks to be optimized away when using the FP exception path. > Are we on the same page with these points? So if you are concerned with the > breakage of existing code, isn't the solution to revert to the previous scope > of the -ff-m-o optimization ASAP, and then if there is a desire to extend the > finite-only optimization to classification functions, *that* would be a new > feature request, perhaps with its own flag? > > > (Note that they are folded to arithmetic, !(x==x), so that transform > > has to be disabled as well, and on some architectures you might get > > library calls because of this instead of inline expansions). > > I'd rather leave comparison optimizations as they are under -ff-m-o, that seems > a sensible expectation of the 'arithmetic' scope, and is relatively well-known, > long-standing effect of -ffast-math. It's only the 5 explicit fp > classification calls which I think deserve protection to allow data validation > in a non-hacky manner before doing core computations with the finite invariant. > > Unless you are saying things like std::isnan cannot be implemented separately > from !(x==x)? That has not been my understanding. No, I said that GCC itself unconditionally transforms isnan to !(x == x) (independent of -ffinite-math-only). If you really want to go forward you have to produce a patch, test it and post it to gcc-patches@gcc.gnu.org. *** This bug has been marked as a duplicate of bug 25975 ***