[Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.