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.)
