[Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904

--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-02 16:13:25 UTC ---
On Fri, 2 Dec 2011, burnus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
> 
> --- Comment #27 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-02 16:02:45 UTC ---
> (In reply to comment #26)
> > The trivial example is (x + 2**52) - 2**52 which rounds x to
> > an integer.  Without parens we optimize away that rounding effect.
> 
> Corrected example. The result I get with other compilers matches the current
> behaviour of GCC/gfortran:
> 
> - GCC: Gives (of course independent of -fno-protect-parens): 1.3 with "-O1
> -ffast-math", 1.0 without -ffast-math.

Indeed GCC does not perform FP association without some sub-flags
enabled by -ffast-math (it assumes then intermediate rounding is
to be preserved).

> - Intel ifort 12.2: -O1 has 1.0, -O2 has 1.3, -assume protect_parens does not
> help but -fp-model strict does (with -O2: 1.0).
> 
> - PGI pgf95 11.5-0: 1.0 with up to -O4.
> 
> - Crayftn 7.1.4.111: 1.0 for -O0, 1.3 for -O1. Option "-O fp0" gives 1.0 while
> already "-O fp1" gives 1.3.
> 
> - PathScale pathf95 3.2.99: 1.0 for up to -O3, -Ofast prints 1.3. As with GCC,
> -OPT:fast_math={on,off} toggles between 1.0 and 1.3
> 
> - NAG f95: 1.0 for up to -O4, 1.3 with -Ounsafe.
> 
> - Sun Fortran 95 8.3: 1.0 for -O4, 1.3 for -fast.
> 
> program test
>   implicit none
>   real(8), volatile :: y
>   y = 1.3d0
>   call sub(y)
>   print *, y
> ! if (y /= 1.0d0) &
> !   call abort
> contains
>   subroutine sub(x)
>     real*8 x, tem
>     tem = x + 2.d0**52
>     x = tem - 2.d0**52
>   end subroutine sub
> end program test

And for the sake of completeness the evaluation of sub above and

   subroutine sub2(x)
     real*8 x
     x = (x + 2.d0**52) - 2.d0**52
   end subroutine sub2

should behave consistently if I read your Fortran standard
quotations correctly.