From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17095 invoked by alias); 3 Dec 2011 14:55:49 -0000 Received: (qmail 17081 invoked by uid 22791); 3 Dec 2011 14:55:49 -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; Sat, 03 Dec 2011 14:55:36 +0000 From: "dominiq at lps dot ens.fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast Date: Sat, 03 Dec 2011 14:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: dominiq at lps dot ens.fr X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: 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-12/txt/msg00240.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 --- Comment #36 from Dominique d'Humieres 2011-12-03 14:54:40 UTC --- > Kind of, though, -ffast-math by itself already is on the verge of violating the > standard. I disagree with this statement at least for codes that does not use IEEE intrinsic modules (not yet implemented in gfortran). Indeed the interaction between -ffast-math and IEEE intrinsic modules will have to be discussed and documented when these modules will be implemented (see pr50724 for the kind of problems). > I think -fno-protect-parens could be enabled by -ffast-math as that > means that one does not really care about the exact value. PLEEEASE DON'T. The situation is bad enough with -Ofast to not make it worse: with -fno-protect-parens gfortran no longer complies with the Fortran standard (7.1.5.2.4 quoted in comment #23) and IMO SHOULD NOT be part of any compound option. Note that if I am using -ffast-math, it is not because I do "not really care about the exact value". It is mostly because I KNOW that exceptions will be the signature of either a bug in my code and/or a bad choice of the parameters leading to numerical instabilities. In top of that, I think that the concept of "exact value" for floating-point numbers is ill-posed and as a consequence I do accept that the least significant digits may depend on the way I write the code or it is optimized (small fluctuations for well-posed methods, large ones otherwise). > If we want to add add extra protection for > tem = x + 2.d0**52 > x = tem - 2.d0**52 > we probably need to add yet another flag as there are surely users, which want > to have protected parentheses but allow for optimizations in the 'tmp' case. If I need an extra protection, I'll put parentheses and I don't need yet another flag. However, since the logic of the optimization is surprising the first time you hit it, it could (should) be documented.