[Patch, Fortran] Enable flag_associative_math (almost) by default

[Tobias Burnus]

The GCC manual claims:

-fassociative-math
Allow re-association of operands in series of floating-point operations.
This violates the ISO C and C++ language standard by possibly changing
computation result. [...] This option requires that both
-fno-signed-zeros and -fno-trapping-math be in effect. [...] For Fortran
the option is automatically enabled when both -fno-signed-zeros and
-fno-trapping-math are in effect.

And related the gfortran manual has:

-fno-protect-parens
By default the parentheses in expression are honoured for all
optimization levels such that the compiler does not do any
re-association. [...] Note that for the reassociation optimization
-fno-signed-zeros and -fno-trapping-math need to be in effect.

If one now looks for flag_associative_math one sees that gfortran does
not touch it at all and also toplev.c has only the trapping/signed zero
check and no special case for Fortran.

Well, the following patch does what is written in the manual; as
-funsave-math-optimization implies both
-fno-trapping-math/-fno-signed-zeros and -fassociate-math -- and as
-ffast-math implies -funsave-math-optimizations, the practical impact of
the change is small.

Note: Even with -ffast-math -fassociate-math, the parentheses are
protected (unless -fno-protect-parens is used).

Build on x86-64-linux.
OK for the trunk?

Tobias

PS: Thanks go to Dominique pointed out the error in the documentation.

PPS: There is also a "(!flag_trapping_math && !flag_signed_zeros)" check
in toplev.c, which prevents enabling -freassociative-math - but the
function prints an ignore warning. Otherwise, one could simply set the
flag to 1 in the option init section.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reassoc.diff
Type: text/x-patch
Size: 1028 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20100506/2f4c37b6/attachment.bin>