[Bug tree-optimization/43716] New: [4.6 Regression] Revision 158105 miscompiles doduc.f90

[Bug tree-optimization/43716] New: [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

In 64 bit mode (default) with ' -O3 -funsafe-math-optimizations
-ffinite-math-only' revision 158105 miscompiles doduc.f90:

 MAIN : FIN S00002
 MAIN : FIN S00001
 MAIN : FIN S00011
 MAIN : FIN S00022
 TEMPS =     33.00000000 , NITERA :          1
 TEMPS =     34.00030857 , NITERA :        186
 TEMPS =     35.00175832 , NITERA :        948
 TEMPS =     36.00201433 , NITERA :       1506
 TEMPS =     37.00275274 , NITERA :       1761
 TEMPS =     38.00327697 , NITERA :       2041
 TEMPS =     39.00023711 , NITERA :       2323
 TEMPS =     40.00315505 , NITERA :       2604
 TEMPS =     45.00271328 , NITERA :       4015
 TEMPS =     50.00242267 , NITERA :       5490
 TEMPS =     55.00059079 , NITERA :       6982
 TEMPS =     60.00004761 , NITERA :       8683
Segmentation fault

instead of

 MAIN : FIN S00002
 MAIN : FIN S00001
 MAIN : FIN S00011
 MAIN : FIN S00022
 TEMPS =     33.00000000 , NITERA :          1
 TEMPS =     34.00031041 , NITERA :        186
 TEMPS =     35.00458344 , NITERA :        952
 TEMPS =     36.00231683 , NITERA :       1503
 TEMPS =     37.00204661 , NITERA :       1752
 TEMPS =     38.00184041 , NITERA :       2030
 TEMPS =     39.00285193 , NITERA :       2313
 TEMPS =     40.00039336 , NITERA :       2592
 TEMPS =     45.00193388 , NITERA :       4002
 TEMPS =     50.00313592 , NITERA :       5477
 TEMPS =     55.00087838 , NITERA :       6968
 TEMPS =     60.00257489 , NITERA :       8304
 TEMPS =     70.00018172 , NITERA :      10771
...
 TEMPS =   1960.00148831 , NITERA :     522874
 TEMPS =   1970.00230662 , NITERA :     525415
 TEMPS =   1980.00310479 , NITERA :     527956
 TEMPS =   1990.00392388 , NITERA :     530497
 TEMPS =   2000.00080221 , NITERA :     533037

In 32 bit mode (with -m32) the compilation is OK

 MAIN : FIN S00002
 MAIN : FIN S00001
 MAIN : FIN S00011
 MAIN : FIN S00022
 TEMPS =     33.00000000 , NITERA :          1
 TEMPS =     34.00030835 , NITERA :        186
 TEMPS =     35.00463561 , NITERA :        950
 TEMPS =     36.00171759 , NITERA :       1507
 TEMPS =     37.00181750 , NITERA :       1759
 TEMPS =     38.00134840 , NITERA :       2037
 TEMPS =     39.00251558 , NITERA :       2320
 TEMPS =     40.00202537 , NITERA :       2599
 TEMPS =     45.00267592 , NITERA :       4007
 TEMPS =     50.00070886 , NITERA :       5482
 TEMPS =     55.00040603 , NITERA :       6974
 TEMPS =     60.00064786 , NITERA :       8664
 TEMPS =     70.00043350 , NITERA :      14927
...
 TEMPS =   1960.00239009 , NITERA :     526412
 TEMPS =   1970.00318777 , NITERA :     528953
 TEMPS =   1980.00005908 , NITERA :     531493
 TEMPS =   1990.00088071 , NITERA :     534034
 TEMPS =   2000.00168409 , NITERA :     536575

The culprit is the subroutine S33022. I'll attach the source for this routine,
the doduc.f90 source with the routine commented and the assembly codes for
S33022 with revision 158104 or older and with revision 158105 or newer.

When compiled with any revision and linked with the object from s33022_w.s, the
code works, but not when linked with the object from s33022_n.s.


-- 
           Summary: [4.6 Regression] Revision 158105 miscompiles doduc.f90
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2010-04-10 16:36 -------
Created an attachment (id=20354)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20354&action=view)
Fortran source for subroutine S33022


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2010-04-10 16:38 -------
Created an attachment (id=20355)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20355&action=view)
Fortran source for doduc.f90 with subroutine S33022 commented


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2010-04-10 16:39 -------
Created an attachment (id=20356)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20356&action=view)
Working assembly for subroutine S33022


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2010-04-10 16:42 -------
Created an attachment (id=20357)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20357&action=view)
Miscompiled assembly for subroutine S3302

The diff between the working (-) and miscompiled (+) assembly files is

--- s33022_w.s  2010-04-10 13:04:09.000000000 +0200
+++ s33022_n.s  2010-04-10 13:04:31.000000000 +0200
@@ -311,13 +311,13 @@ L28:
        movsd   -144(%rbp), %xmm3
        mulsd   %xmm9, %xmm1
        mulsd   %xmm4, %xmm3
-       subsd   -144(%rbp), %xmm14
+       subsd   -136(%rbp), %xmm14
        movsd   -136(%rbp), %xmm9
        divsd   %xmm10, %xmm1
        subsd   %xmm2, %xmm9
        addsd   LC18(%rip), %xmm14
        movsd   %xmm9, -104(%rbp)
-       subsd   -136(%rbp), %xmm14
+       subsd   -144(%rbp), %xmm14
        movsd   (%r8), %xmm10
        movsd   %xmm10, -216(%rbp)
        mulsd   %xmm7, %xmm10
@@ -454,16 +454,13 @@ L28:
        movsd   -88(%rbp), %xmm6
        mulsd   %xmm4, %xmm3
        mulsd   %xmm2, %xmm6
-       xorpd   LC12(%rip), %xmm12
+       mulsd   -232(%rbp), %xmm15
        addsd   -200(%rbp), %xmm14
        mulsd   %xmm9, %xmm3
-       mulsd   -232(%rbp), %xmm15
-       subsd   -216(%rbp), %xmm12
        movsd   %xmm3, -456(%rbp)
        movapd  %xmm13, %xmm3
        mulsd   %xmm1, %xmm14
        addsd   %xmm13, %xmm3
-       mulsd   -80(%rbp), %xmm12
        addsd   %xmm6, %xmm3
        movsd   -120(%rbp), %xmm6
        addsd   %xmm6, %xmm6
@@ -495,13 +492,17 @@ L28:
        mulsd   -112(%rbp), %xmm14
        mulsd   %xmm0, %xmm3
        addsd   %xmm3, %xmm15
-       movsd   -144(%rbp), %xmm3
-       subsd   -120(%rbp), %xmm3
-       subsd   %xmm12, %xmm15
+       movsd   -216(%rbp), %xmm3
+       xorpd   LC12(%rip), %xmm3
+       subsd   %xmm12, %xmm3
        movsd   -136(%rbp), %xmm12
        subsd   -120(%rbp), %xmm12
-       mulsd   %xmm8, %xmm3
+       mulsd   -80(%rbp), %xmm3
        mulsd   -96(%rbp), %xmm12
+       subsd   %xmm3, %xmm15
+       movsd   -144(%rbp), %xmm3
+       subsd   -120(%rbp), %xmm3
+       mulsd   %xmm8, %xmm3
        addsd   %xmm12, %xmm3
        movapd  %xmm4, %xmm12
        mulsd   %xmm0, %xmm12


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[mkuvyrkov at gcc dot gnu dot org]

------- Comment #5 from mkuvyrkov at gcc dot gnu dot org  2010-04-10 18:28 -------
Would you please attach doduc.in so that I can reproduce this.
==
At line 161 of file /home/maxim/tmp/doduc_red.f90 (unit = 5, file = 'doduc.in')
Fortran runtime error: End of file
==

Also, what is your configure line and with which exact parameters f951 gets
invoked?  (The compiler prints out the later if you add `-v' option to the
command line).


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2010-04-10 18:41 -------
Created an attachment (id=20358)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20358&action=view)
doduc.in

Using built-in specs.
COLLECT_GCC=gfcp
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.6p
--mandir=/opt/gcc/gcc4.6p/share/man --infodir=/opt/gcc/gcc4.6p/share/info
--build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10
--target=x86_64-apple-darwin10 --enable-languages=c,fortran
--with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64
Thread model: posix
gcc version 4.6.0 20100408 (experimental) [trunk revision 158105] (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic'
 /opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/f951 doduc_red.f90
-fPIC -quiet -dumpbase doduc_red.f90 -mmacosx-version-min=10.6.3 -mtune=generic
-auxbase doduc_red -version -fintrinsic-modules-path
/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/finclude -o
/var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccrL4xwD.s
GNU Fortran (GCC) version 4.6.0 20100408 (experimental) [trunk revision 158105]
(x86_64-apple-darwin10)
        compiled by GNU C version 4.6.0 20100408 (experimental) [trunk revision
158104], GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20100408 (experimental) [trunk revision 158105]
(x86_64-apple-darwin10)
        compiled by GNU C version 4.6.0 20100408 (experimental) [trunk revision
158104], GMP version 5.0.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic'
 as -arch x86_64 -force_cpusubtype_ALL -o doduc_red.o
/var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccrL4xwD.s
COMPILER_PATH=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/:/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/
LIBRARY_PATH=/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/:/opt/gcc/gcc4.6p/lib/gcc/x86_64-apple-darwin10/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic'
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.3' '-v' '-c' '-mtune=generic'


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #7 from dominiq at lps dot ens dot fr  2010-04-10 18:49 -------
The problem seems to occur within these lines:

               tt = -t*rmp/rm
               z1at = -Dalb - Dalt
               z2at = drg*(alt-2.*al) + drf*(alb-2.*al) + rg*Dalt +     &
     &                rf*Dalb
               sdt = z2at*vgj + z2a*vgjt + z2t*vgja + z2*vgjat - g*z1at


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[mkuvyrkov at gcc dot gnu dot org]

------- Comment #8 from mkuvyrkov at gcc dot gnu dot org  2010-04-10 19:20 -------
Hm, I'm having hard time reproducing this on linux.  Would you please attach
dumps produced with -fdump-tree-reassoc for both before and after compilers.

Thanks.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|maxim at trivialbugs dot com|mkuvyrkov at gcc dot gnu dot
                   |                            |org


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2010-04-10 19:32 -------
Created an attachment (id=20359)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20359&action=view)
bzipped tar file with the outputs of -fdump-tree-reassoc

reassoc.tar.bz2 contains the files s33022_*.f90.082t.reassoc1 and
s33022_*.f90.121t.reassoc2, with *==w for the working compiler and *==n for the
non-working one.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-04-12 11:21 -------
-  D.1850_209 = -alt_90;
-  D.2093_151 = -alb_86;
-  D.1849_208 = D.1848_207 - alb_86;
+  D.2093_151 = -alt_90;
+  D.1849_208 = D.1848_207 - alt_90;
   D.1851_210 = D.1849_208 + -1.0e+0;
-  z1a_211 = D.1851_210 + D.1850_209;
+  D.2094_497 = -alb_86;
+  z1a_211 = D.1851_210 - alb_86;

this doesn't look like an identity transform.  You have to be careful with
non-single use vars and make sure they do not end up on a reassociation
chain.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[mkuvyrkov at gcc dot gnu dot org]

------- Comment #11 from mkuvyrkov at gcc dot gnu dot org  2010-04-12 16:38 -------
Confirmed with mac os x gcc build.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mkuvyrkov at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-12 16:38:52
               date|                            |


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2010-04-13 14:09 -------
A few additional notes:

(1) with revision 158105 reverted, the test gcc.dg/tree-ssa/reassoc-19.c fails
with -m32, but passes with -m64.

(2) revision 158265 with/without revision 158105 reverted (after some surgery
to replace plus_negates with broken_up_subtracts) also miscompiles doduc.f90.

(3) Following comment #10, is it possible to rule out a critical loss of
precision due to the reassociation?

(4) From Jerry Delisle, the diff before and after r158105 on fedora is

$ diff s33022.s.before s33022.s.after
315c315
<       subsd   296(%rsp), %xmm14
---
> 	subsd	288(%rsp), %xmm14
321c321
<       subsd   288(%rsp), %xmm14
---
> 	subsd	296(%rsp), %xmm14
458c458
<       xorpd   .LC12(%rip), %xmm12
---
> 	mulsd	384(%rsp), %xmm15
461,462d460
<       mulsd   384(%rsp), %xmm15
<       subsd   368(%rsp), %xmm12
467d464
<       mulsd   232(%rsp), %xmm12
499,501c496,498
<       movsd   296(%rsp), %xmm3
<       subsd   272(%rsp), %xmm3
<       subsd   %xmm12, %xmm15
---
> 	movsd	368(%rsp), %xmm3
> 	xorpd	.LC12(%rip), %xmm3
> 	subsd	%xmm12, %xmm3
504c501
<       mulsd   %xmm8, %xmm3
---
> 	mulsd	232(%rsp), %xmm3
505a503,506
> 	subsd	%xmm3, %xmm15
> 	movsd	296(%rsp), %xmm3
> 	subsd	272(%rsp), %xmm3
> 	mulsd	%xmm8, %xmm3


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[mkuvyrkov at gcc dot gnu dot org]

------- Comment #13 from mkuvyrkov at gcc dot gnu dot org  2010-04-13 19:32 -------
The SIGSEGV is due to -funsafe-math-optimizations being used with code like:
==
      Re = eps*debm*DIAhy/(vis*sec)
      reo = Re
      IF ( Re.LT.1000. ) THEN
         i1 = INT(Re/200.) + 1
      ELSEIF ( Re.LT.4000. ) THEN
         i1 = INT(Re/500.) + 4
      ELSEIF ( Re.LT.10000. ) THEN
         i1 = INT(Re/2000.) + 10
      ELSEIF ( Re.GE.30000. ) THEN
         IF ( Re.GE.49999. ) Re = 49999.D+00
         i1 = INT(Re/10000.) + 16
      ELSE
         i1 = INT(Re/5000.) + 13
      ENDIF
      i2 = i1 + 1
      y1 = y(i1)
      y2 = y(i2)
==

Here we have index `i1' calculated from fp values and then casted to int. 
Segmentation fault occurs in `y1 = y(i1)' with i1 equal to 0xffffffff8000000c. 
This is in function S00061 in doduc_red.f90, not in s33022.f90.

Also, to trigger the SIGSEGV it is necessary to compile both doduc_red.f90 and
s33022.f90 with "-O3 -funsafe-math-optimizations -ffinite-math-only".  If
either of the modules is compiled with -O2 the SIGSEGV does not occur.

While I will not argue that my patch is 100% bug-free, this seems to be an
invalid testcase.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[mkuvyrkov at gcc dot gnu dot org]

------- Comment #14 from mkuvyrkov at gcc dot gnu dot org  2010-04-13 20:01 -------
(In reply to comment #10)
> -  D.1850_209 = -alt_90;
> -  D.2093_151 = -alb_86;
> -  D.1849_208 = D.1848_207 - alb_86;
> +  D.2093_151 = -alt_90;
> +  D.1849_208 = D.1848_207 - alt_90;
>    D.1851_210 = D.1849_208 + -1.0e+0;
> -  z1a_211 = D.1851_210 + D.1850_209;
> +  D.2094_497 = -alb_86;
> +  z1a_211 = D.1851_210 - alb_86;
> 
> this doesn't look like an identity transform.  You have to be careful with
> non-single use vars and make sure they do not end up on a reassociation
> chain.

Though it does look fishy, this transformation is OK.  In fact, the compiler
oscillates a couple of times between using `-alb_86' and `-alt_90'.  E.g., the
"before" compiler does the following transformation during reassoc1:
==
-  D.1849_208 = D.1848_207 - alb_86;
+  D.2045_228 = -alb_86;
+  D.1850_209 = -alt_90;
+  D.1849_208 = D.1848_207 + D.1850_209;
==


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #15 from dominiq at lps dot ens dot fr  2010-04-13 20:45 -------
(In reply to comment #13)
> Here we have index `i1' calculated from fp values and then casted to int. 
> Segmentation fault occurs in `y1 = y(i1)' with i1 equal to 0xffffffff8000000c. 
> This is in function S00061 in doduc_red.f90, not in s33022.f90.

This is because Re is a NaN because debm is a NaN. I tried to print deve and
devs, but this make the code to work.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2010-04-14 09:44 -------
Well, it indeed looks invalid if there is NaNs involved and you use
-ffinite-math-only.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2010-04-14 09:55 -------
> Well, it indeed looks invalid if there is NaNs involved and you use
> -ffinite-math-only.

The NaN appears in the miscompiled executable. Note that I am not the author of
the doduc test, but it has been compiled by gfortran with -O3 -ffast-math for
years and ran without failure.

> While I will not argue that my patch is 100% bug-free, this seems to be an
> invalid testcase.

It may happen that the changes in revision 158105 is exposing a latent bug.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[maxim at codesourcery dot com]

------- Comment #18 from mkuvyrkov at gcc dot gnu dot org  2010-04-14 10:02 -------
Subject: Re:  [4.6 Regression] Revision 158105
 miscompiles doduc.f90

On 4/14/10 1:55 PM, dominiq at lps dot ens dot fr wrote:
> ------- Comment #17 from dominiq at lps dot ens dot fr  2010-04-14 09:55 -------
>> Well, it indeed looks invalid if there is NaNs involved and you use
>> -ffinite-math-only.
>
> The NaN appears in the miscompiled executable. Note that I am not the author of
> the doduc test, but it has been compiled by gfortran with -O3 -ffast-math for
> years and ran without failure.

Can you track where the NaN comes from and if it is indeed unexpected 
even with -ffast-math -ffinite-math-only?

>> While I will not argue that my patch is 100% bug-free, this seems to be an
>> invalid testcase.
>
> It may happen that the changes in revision 158105 is exposing a latent bug.

That is always a possibility.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2010-04-14 10:25 -------
> Can you track where the NaN comes from and if it is indeed unexpected 
> even with -ffast-math -ffinite-math-only?

First '-ffast-math' implies '-funsafe-math-optimizations -ffinite-math-only'.

To reach

> This is because Re is a NaN because debm is a NaN. I tried to print deve and
> devs, but this make the code to work.

I have added an IF in S00061 that print some results if i1 is less than 1 or
greater than 20 (i.e., a poor man's bound check). With that I see that Re is a
NaN when the code crashes an nothing when the code works (e.g., after reverting
revision 158105). The bad news is that the code "works" if I try to print the
variables deve or devs (Re=(deve+devs)/2.0) and I did not find a way to
overcome it. From my experience, a change of behavior when printing something
is a good clue that there is some memory mismanagement (usually due to using
arrays outside their bounds).

Note also that S00061 is compiled the same way before of after r158105 (I have
even checked it before opening this pr).

I have no knowledge at all of doduc (see http://www.spec.org/cpu92/DESCR.015 ).
The first time I heard anything about it (~20 years ago) was because it was
considered at that time as a "compiler breaker".


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #20 from dominiq at lps dot ens dot fr  2010-04-14 13:06 -------
I have been able to get the following values before the crash:

DEBav = 

0.59252398402327489       1.58848116996742547E-002  2.31157896165751706E-002  
8.33002598145726886E-002  9.03564427292446321E-002  -596152.33325048804       
-173.27129371256277        284192.62549692224       -226.34926169938268       
-2145.2785283028134        6880.2385948782830        25825.135912393274        
26997.892028831531                            NaN   0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000

XA = 

0.0000000000000000        1.0000000000000000        1.0000000000000000        
1.0000000000000000        1.0000000000000000        1.0000000000000000        
1.0000000000000000       0.99999999999999989        1.0000000000000000        
1.0000000000000000        1.0000000000000000       0.49470835610659347       
                    NaN                       NaN   0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000  

XB =

0.0000000000000000        0.0000000000000000       4.95714580495132420E-018   
0.0000000000000000        0.0000000000000000        0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000        
0.0000000000000000        0.0000000000000000       7.34677397984116187E-002   
                    NaN                       NaN   0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000        
0.0000000000000000        0.0000000000000000        0.0000000000000000

ie = I - 1
debe = DEBav(ie)
debs = DEBav(I)
deve = XA(ie)*debe + XB(ie)
devs = XA(I)*debs + XB(I)
sec = SCApa(I)
debm = (deve+devs)/2.D+00
eps = 1.D+00
IF ( debm.LT.0. ) eps = -1.D+00
vis = (r+s*tf)/3600.D+00
Re = eps*debm*DIAhy/(vis*sec)

So if I= 13, 14, or 15, Re is a NaN.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[mkuvyrkov at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]



------- Comment #21 from mkuvyrkov at gcc dot gnu dot org  2010-05-05 20:28 -------
Dominique,

Have you been able to identify if there is an invalid optimization?

It seems using -ffast-math -ffinite-math-only is very error-prone.  -ffast-math
implies -fassociative-math, which can generate NaNs, and -ffinite-math-only can
further worsen the precision by additional optimizations.

It may not be obvious to a casual GCC user that -ffinite-math-only gives more
freedom to the optimization passes, not restricts the compiler to keep all math
finite.

FYI,

-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 computa- tion
result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs
and inhibit or create underflow or overflow (and thus cannot be used on a code
which relies on rounding behavior like (x + 2**52) - 2**52). May also reorder
floating-point comparisons and thus may not be used when ordered comparisons
are required. This option requires that both ‘-fno-signed-zeros’ and
‘-fno-trapping-math’ be in effect. Moreover, it doesn’t make much sense with
‘-frounding-math’. For Fortran the option is automatically enabled when both
‘-fno-signed-zeros’ and ‘-fno-trapping-math’ are in effect.
The default is ‘-fno-associative-math’.
...
-ffinite-math-only
Allow optimizations for floating-point arithmetic that assume that arguments
and results are not NaNs or +-Infs.
This option is not turned on by any ‘-O’ option since it can result in
incorrect output for programs which depend on an exact implementation of IEEE
or ISO rules/specifications for math functions. It may, however, yield faster
code for programs that do not require the guarantees of these specifications.
The default is ‘-fno-finite-math-only’.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #22 from dominiq at lps dot ens dot fr  2010-05-06 14:59 -------
> Have you been able to identify if there is an invalid optimization?

I have started to follow the spaghetti plate without success so far. However,
although I don't think the problem comes from any "invalid optimization", I
realized that '-funsafe-math-optimizations' (implied by -ffast-math) implies
'-freciprocal-math'. Thus with a vanilla trunk at revision 159085 (gfcp), I
tried:

gfcp -O3 -ffast-math -fno-reciprocal-math ../doduc.f90

which worked. Then I did the following change:

--- doduc.f90   2005-10-11 14:53:32.000000000 +0200
+++ doduc_nr.f90        2010-05-06 15:38:37.000000000 +0200
@@ -2378,13 +2378,13 @@
             dvg = DNUg(I)
             drf = -dvf*rf*rf
             drg = -dvg*rg*rg
-            rp = r*(dvf/vf-dvg/vg)
+            rp = r*(dvf*rf-dvg/vg)
             alo = .925*(vf/vg)**.239
             a = .67
             IF ( al.GE.alo ) a = .47
             vgj = VGJo(I)
             alop = alo*rp*.239/r
-            vbcrp = .25*vbcr*(dvf/vf-rp/(1.-r))
+            vbcrp = .25*vbcr*(dvf*rf-rp/(1.-r))
             alb = ALFb(I)
             alt = ALFt(I)
             tao = alop/(a*alo)

(since rf = 1./vf) and it worked too (note that it did not with only one change
in rp or vbcrp).

Now the questions are:
(1) why a change dealing with the propagation of minus signs interferes with
reciprocal-math?
(2) why moving VEC_safe_push from negate_value to eliminate_plus_minus_pair
trigger the miscompilation?


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[maxim at codesourcery dot com]

------- Comment #23 from mkuvyrkov at gcc dot gnu dot org  2010-05-06 15:07 -------
Subject: Re:  [4.6 Regression] Revision 158105
 miscompiles doduc.f90

On 5/6/10 6:59 PM, dominiq at lps dot ens dot fr wrote:
...
> Now the questions are:
> (1) why a change dealing with the propagation of minus signs interferes with
> reciprocal-math?
> (2) why moving VEC_safe_push from negate_value to eliminate_plus_minus_pair
> trigger the miscompilation?

Just to be clear, I do not think there is a miscompilation here.

The patch that [among other things] moved VEC_safe_push from 
negate_value to eliminate_plus_minus_pair did that to enable "(a + (-b)) 
-> (a - b)" optimization in more cases.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #24 from dominiq at lps dot ens dot fr  2010-05-06 15:34 -------
> > Now the questions are:
> > (1) why a change dealing with the propagation of minus signs interferes with
> > reciprocal-math?
> > (2) why moving VEC_safe_push from negate_value to eliminate_plus_minus_pair
> > trigger the miscompilation?
>
> Just to be clear, I do not think there is a miscompilation here.

Just to be clear,

(1) I have understood your point from the very beginning,
(2) I disagree with it: if you get the right result with '-O3 -ffast-math' on
*-linux-* and I get a segmentation fault on x86_64-apple-darwin10, it means
that doduc.f90 is miscompiled for the latter.
Note that I have gotten the correct result for doduc.f90 with '-O3 -ffast-math'
several hundred times over the past years.

> The patch that [among other things] moved VEC_safe_push from 
> negate_value to eliminate_plus_minus_pair did that to enable "(a + (-b)) 
> -> (a - b)" optimization in more cases.

Unless I missed something, the only significant change in revision 158105 is
the move of VEC_safe_push. The other ones are renaming "broken_up_subtracts" to
"plus_negates" and moving
static VEC(tree, heap) *plus_negates;
where it is needed due to the move of VEC_safe_push. Unless there is something
very weird, I cannot see how these two changes can affect the generated code.

Note also that if the only effect of moving VEC_safe_push was to enable "(a +
(-b))-> (a - b)" optimization, it should not interfere with the optimization
"a/b -> a*(1.0/b))".


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #25 from dominiq at lps dot ens dot fr  2010-05-08 10:31 -------
This PR is "fixed" by revision 159106. Apparently there is a rampant bug (at
least on Darwin) with the use of "VEC_safe_push".

How safe is "VEC_safe_push"?


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard dot guenther at
                   |                            |gmail dot com


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[steven at gcc dot gnu dot org]

------- Comment #26 from steven at gcc dot gnu dot org  2010-05-08 10:38 -------
VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you
really believe that VEC_safe_push is the problem here, then you should perhaps
look if a VEC is being passed around incorrectly somewhere, so that
reallocating it would make things disappear.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #27 from dominiq at lps dot ens dot fr  2010-05-09 14:19 -------
> VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you
> really believe that VEC_safe_push is the problem here, then you should perhaps
> look if a VEC is being passed around incorrectly somewhere, so that
> reallocating it would make things disappear.

Could you give me more precise idea about what I am supposed to do to "look if
a VEC is being passed around incorrectly somewhere"? BTW I would think the
problem is not before some "reallocation", but after it, see:

   ... .  The latter will reallocate the
   vector, if needed.  Reallocation causes an exponential increase in
   vector size.  ....

I have found a long comment at the beginning of gcc/vec.h, is VEC_safe_push
documented elsewhere?

I have done the following changes in the subroutine s00009.f90:

(1) 

--- s00009.f90  2010-04-18 22:04:36.000000000 +0200
+++ s00009_yy.f90       2010-05-09 15:19:43.000000000 +0200
@@ -45,6 +45,7 @@
      &                NDPdt , NDBsor , NHSor
       DOUBLE PRECISION M , cc(22,2)
       coef = 144.D+00/778.D+00
+      zzz = 1.0/VVFs
       DO i = 2 , NC1
         j = i - 1
         ity = ITYp(i)

and I get the same assembly compared with the original one (for both revision
159105 and 159106).

(2)

--- s00009.f90  2010-04-18 22:04:36.000000000 +0200
+++ s00009_xx.f90       2010-05-09 15:22:25.000000000 +0200
@@ -45,6 +45,7 @@
      &                NDPdt , NDBsor , NHSor
       DOUBLE PRECISION M , cc(22,2)
       coef = 144.D+00/778.D+00
+      zzz = 1.0/VVFs
       DO i = 2 , NC1
         j = i - 1
         ity = ITYp(i)
@@ -76,7 +77,7 @@
            AA(i,k) = VV(i,k)*DM(i,k) + DVVh(i,k)*cc(i,k)
            DV(i,k) = AA(i,k) + BB(i,k)*DPDt
            IF ( DABS(DV(i,k)).LT.1.D-10 ) DV(i,k) = 0.D+00
-           epsm = DELm*VC(i)/VVFs
+           epsm = DELm*VC(i)*zzz
            ym = M(i,k)
            IF ( ym.LT.epsm ) ym = epsm
            DH(i,k) = (cc(i,k)+coef*V(i,k)*DPDt)/ym

i.e., I have replaced the division with the multiplication by the inverse (if I
am not mistaken, this optimization is done with revision 159105 but not with
159106). The assembly is very different and the executable does not crash.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[dominiq at lps dot ens dot fr]

------- Comment #28 from dominiq at lps dot ens dot fr  2010-06-05 09:54 -------
Is there any interest to understand what broke the test and what fixed it? If
not, I'll close this pr as fixed.


-- 


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

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

[rguenth at gcc dot gnu dot org]

------- Comment #29 from rguenth at gcc dot gnu dot org  2010-06-05 10:36 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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