From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16053 invoked by alias); 2 Dec 2011 14:32:15 -0000 Received: (qmail 16037 invoked by uid 22791); 2 Dec 2011 14:32:13 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM 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; Fri, 02 Dec 2011 14:32:00 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast Date: Fri, 02 Dec 2011 14:32: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: rguenther at suse dot de 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/msg00164.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 --- Comment #24 from rguenther at suse dot de 2011-12-02 14:31:27 UTC --- On Fri, 2 Dec 2011, burnus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 > > Tobias Burnus changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |burnus at gcc dot gnu.org, > | |kargl at gcc dot gnu.org, > | |pault at gcc dot gnu.org > > --- Comment #23 from Tobias Burnus 2011-12-02 14:03:41 UTC --- > (In reply to comment #22) > > I wonder if Fortran [...] > > Well, let's start with the Fortran standard (Fortran 2008): > > "7.1.5.2.4 Evaluation of numeric intrinsic operations > > "The execution of any numeric operation whose result is not defined by the > arithmetic used by the processor is prohibited. Raising a negative-valued > primary of type real to a real power is prohibited. > > "Once the interpretation of a numeric intrinsic operation is established, the > processor may evaluate any mathematically equivalent expression, provided that > the integrity of parentheses is not violated. > > "Two expressions of a numeric type are mathematically equivalent if, for all > possible values of their primaries, their mathematical values are equal. > However, mathematically equivalent expressions of numeric type may produce > different computational results." > > [The section then contains a few non-normative notes; cf. > http://gcc.gnu.org/wiki/GFortranStandards#Fortran_2008 ] > > And for the assignment: > > "7.2.1 Assignment statement" [...] > "R732 assignment-stmt is variable = expr" > [...] > "Execution of an intrinsic assignment causes, in effect, the evaluation of the > expression expr and all expressions within variable (7.1), the possible > conversion of expr to the type and type parameters of the variable (Table 7.9), > and the definition of the variable with the resulting value. The execution of > the assignment shall have the same effect as if the evaluation of expr and the > evaluation of all expressions in variable occurred before any portion of the > variable is defined by the assignment. The evaluation of expressions within > variable shall neither affect nor be affected by the evaluation of expr." > > > > with -fprotect-parens, really has different semantics for > > tem = 2 * a; > > c = b / tem; > > vs. > > c = b / (2 * a); > > ? > > > > Thus, is not every statement supposed to be wrapped in parens with > > -fprotect-parens? So that > > tem = 2 * a; > > becomes > > tem = ( 2 * a ); > > implicitely? > [...] > > Thus, this is a question of 1) correctness of the -fprotect-parens > > implementation in the frontend, 2) a question on what optimizations > > we want to perform on protected expressions. > > It somehow looks as if one needs to add implicitly parentheses; this gets more > complicated, if one takes the scalarizer or inlining into account. > > Contrary to the explicit parentheses, I am not aware of a program which breaks > with the extra temporary, but that's does not tell much. (Side note: I think > the majority of users doesn't care [or know] about the protection of either > parentheses or the separate assignment statements - and is happy as long the > result is mathematical the same. Though, some users do care as with unprotected > parentheses their program breaks.) Every program that would break with non honoring explicit parantheses would also break if the bracketed expression would be explicitely computed into a temporary (without explicit parantheses). So it should be easy to construct a testcase if you have one that breaks without -fno-protect-parens. Richard.