[PATCH] Add PAREN_EXPR

[Tim Prince]

Toon Moene wrote:
> Richard Guenther wrote:
> 
>> To make sure we do not regress too much
>> I have put the patch (and one followup) through Polyhedron testing
>> (with -ffast-math but still honoring parantheses) and the only effect
>> that _maybe_ is not noise is on doduc (though doduc varies quite much,
>> usually locally its quite stable).
>>
>> See
>> http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
>>
>>
>> So I have now applied the first patch (without the hunk trying to make
>> -fassociative-math the default) and will post the followup in a moment.
> 
> Note that quite a few Fortran programmers do not know that compilers are
> free to rearrange expressions without parentheses.  So it could simply
> be that dudoc hasn't been written very carefully.
> 
> E.g., the following program has three interpretations, all valid:
> 
>       READ*,X,Y,Z
>       PRINT*,X+Y+Z
>       END
> 
For years, I've assumed that some of these problems stemmed from so many
compilers attempting to apply the same rules to Fortran and C.
For a slight digression, a question which has assumed importance recently
in my real job is whether a processor need evaluate a given expression the
same way each time.
Vectorized sum reduction on several platforms chooses  an order which
depends on alignments of the operands.  I have assumed this was the reason
gfortran requires -ffast-math to permit it.  If the operand alignment is
under control (e.g. requiring ALLOCATE to provide consistent alignments),
there is no problem.
It turns out a well known MPI run-time may vary the order of operations in
MPI_Allreduce, depending on the order of arrival, requiring promotion to
double precision, or explicitly written substitutes for MPI_Allreduce, to
enable analyses which otherwise could be done in single.