[Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast
rguenther at suse dot de
gcc-bugzilla@gcc.gnu.org
Fri Dec 2 14:32:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #24 from rguenther at suse dot de <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 <burnus at gcc dot gnu.org> 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 <burnus at gcc dot gnu.org> 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.
More information about the Gcc-bugs
mailing list