[Bug fortran/35418] New: [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[Bug fortran/35418] New: [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[hjl dot tools at gmail dot com]

On Linux/Intel64, gcc 4.4 revision 132592 miscompiles 172.mgrid in SPEC CPU 2K
with -O2 -ffast-math. This part of change:

Index: gcc/fortran/trans-array.c
===================================================================
--- gcc/fortran/trans-array.c   (revision 132591)
+++ gcc/fortran/trans-array.c   (revision 132592)
@@ -3937,10 +3949,10 @@ gfc_trans_array_bounds (tree type, gfc_s

          /* Make sure that negative size arrays are translated
             to being zero size.  */
-         tmp = build2 (GE_EXPR, boolean_type_node,
-                       stride, gfc_index_zero_node);
-         tmp = build3 (COND_EXPR, gfc_array_index_type, tmp,
-                       stride, gfc_index_zero_node);
+         tmp = fold_build2 (GE_EXPR, boolean_type_node,
+                            stride, gfc_index_zero_node);
+         tmp = fold_build3 (COND_EXPR, gfc_array_index_type, tmp,
+                            stride, gfc_index_zero_node);
          gfc_add_modify_expr (pblock, stride, tmp);
         }

miscompiles RESID, which has nested loops on 3-d arrays. Does it ring a bell?


-- 
           Summary: [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[hjl dot tools at gmail dot com]

------- Comment #1 from hjl dot tools at gmail dot com  2008-03-01 22:50 -------
The code looks like

      SUBROUTINE RESID(U,V,R,N,A)
      INTEGER N
      REAL*8 U(N,N,N),V(N,N,N),R(N,N,N),A(0:3)
      INTEGER I3, I2, I1

      DO 600 I3=2,N-1
      DO 600 I2=2,N-1
      DO 600 I1=2,N-1

N is a 4 byte integer and gcc uses 8byte integer for array bound.


-- 


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2008-03-01 22:59 -------
Define "miscompiles"?  

Remove -ffast-math?

Add -fbounds-check?


-- 


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[tobi at gcc dot gnu dot org]

------- Comment #3 from tobi at gcc dot gnu dot org  2008-03-01 23:15 -------
I checked the code leading up to this, and if I didn't miss a codepath, stride
will always be of type gfc_array_index_type, so I'm inclined to believe that
the bug, if any, is in fold.  It is of course possible that folding allowed for
a valid optimization that broke 172.mgrid.


-- 


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[hjl dot tools at gmail dot com]

------- Comment #4 from hjl dot tools at gmail dot com  2008-03-02 01:11 -------
I got

  Running 172.mgrid ref base o2 default
*** Miscompare of mgrid.out, see
/export/gnu/import/rrs/spec/2000/spec/benchspec
/CFP2000/172.mgrid/run/00000002/mgrid.out.mis
Invalid run; unable to continue.  If you wish to ignore errors please use '-I'
o
r ignore_errors

Remove -ffast-math fixes the problem. -fbounds-check doesn't make
a difference. I'd like to know why

--- old/c.f.003t.original       2008-03-01 14:15:12.000000000 -0800
+++ new/c.f.003t.original       2008-03-01 14:14:53.000000000 -0800
@@ -36,39 +36,39 @@ resid (u, v, r, n, a)

   ubound.0 = (integer(kind=8)) *n;
   stride.2 = NON_LVALUE_EXPR <ubound.0>;
-  stride.2 = stride.2 >= 0 ? stride.2 : 0;
+  stride.2 = MAX_EXPR <stride.2, 0>;
   ubound.1 = (integer(kind=8)) *n;
   stride.4 = stride.2 * NON_LVALUE_EXPR <ubound.1>;
-  stride.4 = stride.4 >= 0 ? stride.4 : 0;
+  stride.4 = MAX_EXPR <stride.4, 0>;
   ubound.3 = (integer(kind=8)) *n;
   size.6 = stride.4 * NON_LVALUE_EXPR <ubound.3>;
-  size.6 = size.6 >= 0 ? size.6 : 0;
+  size.6 = MAX_EXPR <size.6, 0>;
   D.965 = size.6 - 1;
   D.966 = (bit_size_type) size.6 * 64;
   D.967 = (<unnamed-unsigned:64>) size.6 * 8;
   offset.5 = ~NON_LVALUE_EXPR <stride.2> - NON_LVALUE_EXPR <stride.4>;
   ubound.14 = (integer(kind=8)) *n;
   stride.16 = NON_LVALUE_EXPR <ubound.14>;
-  stride.16 = stride.16 >= 0 ? stride.16 : 0;
+  stride.16 = MAX_EXPR <stride.16, 0>;
   ubound.15 = (integer(kind=8)) *n;
   stride.18 = stride.16 * NON_LVALUE_EXPR <ubound.15>;
-  stride.18 = stride.18 >= 0 ? stride.18 : 0;
+  stride.18 = MAX_EXPR <stride.18, 0>;
   ubound.17 = (integer(kind=8)) *n;
   size.20 = stride.18 * NON_LVALUE_EXPR <ubound.17>;
-  size.20 = size.20 >= 0 ? size.20 : 0;
+  size.20 = MAX_EXPR <size.20, 0>;
   D.962 = size.20 - 1;
   D.963 = (bit_size_type) size.20 * 64;
   D.964 = (<unnamed-unsigned:64>) size.20 * 8;
   offset.19 = ~NON_LVALUE_EXPR <stride.16> - NON_LVALUE_EXPR <stride.18>;
   ubound.7 = (integer(kind=8)) *n;
   stride.9 = NON_LVALUE_EXPR <ubound.7>;
-  stride.9 = stride.9 >= 0 ? stride.9 : 0;
+  stride.9 = MAX_EXPR <stride.9, 0>;
   ubound.8 = (integer(kind=8)) *n;
   stride.11 = stride.9 * NON_LVALUE_EXPR <ubound.8>;
-  stride.11 = stride.11 >= 0 ? stride.11 : 0;
+  stride.11 = MAX_EXPR <stride.11, 0>;
   ubound.10 = (integer(kind=8)) *n;
   size.13 = stride.11 * NON_LVALUE_EXPR <ubound.10>;
-  size.13 = size.13 >= 0 ? size.13 : 0;
+  size.13 = MAX_EXPR <size.13, 0>;
   D.959 = size.13 - 1;
   D.960 = (bit_size_type) size.13 * 64;
   D.961 = (<unnamed-unsigned:64>) size.13 * 8;

makes such a big differece.


-- 


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2008-03-02 01:33 -------
(In reply to comment #4)
> I got
> 
>   Running 172.mgrid ref base o2 default
> *** Miscompare of mgrid.out, see
> /export/gnu/import/rrs/spec/2000/spec/benchspec
> /CFP2000/172.mgrid/run/00000002/mgrid.out.mis
> Invalid run; unable to continue.  If you wish to ignore errors please use '-I'
> o
> r ignore_errors
> 
> Remove -ffast-math fixes the problem. -fbounds-check doesn't make
> a difference. I'd like to know why
> 
> --- old/c.f.003t.original       2008-03-01 14:15:12.000000000 -0800
> +++ new/c.f.003t.original       2008-03-01 14:14:53.000000000 -0800
> @@ -36,39 +36,39 @@ resid (u, v, r, n, a)
> 
>    ubound.0 = (integer(kind=8)) *n;
>    stride.2 = NON_LVALUE_EXPR <ubound.0>;
> -  stride.2 = stride.2 >= 0 ? stride.2 : 0;
> +  stride.2 = MAX_EXPR <stride.2, 0>;

This looks like a middle-end problem.  


-- 


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2008-03-02 10:31 -------
The foldings look legit.  I wonder in which dump there starts to be a real
difference?  I suppose maybe the vectorizer now can do work if not faced with
a COND_EXPR.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-03-02 11:00 -------
Note the COND_EXRPs will be lowered to control-flow while the MAX_EXPRs will
retain a single BB.  Still, on i686 the exactly same inner loop IL is created.

And btw I don't see mgrid miscomparing on our tester that runs with -O3 vs.
-O3 -funroll-loops -fpeel-loops -ffast-math.  But indeed the other tester
with -O2 -ffast-math vs. -O2 -ffast-math with FDO miscompares since Feb. 25
(not so with 32bit or on IA64 though).


-- 


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-03-05 21:53:04
               date|                            |


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[hjl dot tools at gmail dot com]

------- Comment #8 from hjl dot tools at gmail dot com  2008-03-06 22:03 -------
This is a known issue with mgrid. The absolute tolerance is too
small. After increasing absolute tolerance from 1.0e-12 to
1.0e-11, the miscomparison is gone.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2008-08-22 15:02 -------
*** Bug 36983 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joey dot ye at intel dot com


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