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

[Tobias Burnus <burnus at net-b dot de>]

*ping*
http://gcc.gnu.org/ml/fortran/2010-05/msg00033.html

On 05/06/2010 02:24 PM, Tobias Burnus wrote:
> 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.
>