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.
