[Bug fortran/52621] New: ICE when compiling Fortran77 code with optimization

[Bug fortran/52621] New: ICE when compiling Fortran77 code with optimization

[pepalogik at seznam dot cz]

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

             Bug #: 52621
           Summary: ICE when compiling Fortran77 code with optimization
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pepalogik@seznam.cz


Created attachment 26920
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26920
Library source producing the ICE

I am compiling an old Fortran 77 code on Windows XP. I have fixed this code to
make it basically work in both FTN95 (Silverfrost) and gfortran compilers. But
when I try to make a highly optimized build with gfortran, I get an ICE.

Compiler version:
C:\MinGW\bin>gfortran.exe -v
Using built-in specs.
COLLECT_GCC=gfortran.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.1/configure
--enable-languages=c,c++,fortran,objc,ob
j-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp
-
-disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runti
me-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.1 (GCC)

Command:
gfortran.exe -std=legacy -march=native -mfpmath=sse -m3dnow -mmmx -msse -msse2
-msse3  -O3   -Wall    -c D:\Jenda\cbp\SATLEED\LEEDSATL_SB\leedsatl_sb.f -o
obj\Release\leedsatl_sb.o

CPU: AMD Athlon x2, see
<http://www.cpu-world.com/CPUs/K8/AMD-Athlon%20X2%204850e%20-%20ADH4850IAA5DO%20(ADH4850DOBOX).html>

Important: The ICE is gone if I decrease the optimization level to -O2 or
exclude the machine specific options (from -march to -msse3).

The code and output are attached.

Copyright note: The code comes from
<http://www.ap.cityu.edu.hk/personal-website/Van-Hove_files/leed/leedpack.html>
and I am actually not allowed to distribute it.

[Bug fortran/52621] ICE when compiling Fortran77 code with optimization

[pepalogik at seznam dot cz]

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

--- Comment #1 from Jan Lachnitt <pepalogik at seznam dot cz> 2012-03-19 16:13:22 UTC ---
Created attachment 26921
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26921
Compiler output

[Bug fortran/52621] ICE when compiling Fortran77 code with optimization

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-20 08:38:27 UTC ---
Seems to work without ICE using GCC 4.8 (on x86-64-linux) with your options. (I
can currently not test 4.6).

You could try a newer version to see whether it has been fixed in the mean
time. See for instance http://gcc.gnu.org/wiki/GFortranBinaries

[Bug fortran/52621] ICE when compiling Fortran77 code with optimization

[pepalogik at seznam dot cz]

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

--- Comment #3 from Jan Lachnitt <pepalogik at seznam dot cz> 2012-03-21 12:18:59 UTC ---
Thanks for testing and for the link to GFortranBinaries. I have just installed
the very recent unofficial build of gfortran:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/program
files/gfortran/bin/../libexec/gcc/i586-pc-mingw32
/4.8.0/lto-wrapper.exe
Target: i586-pc-mingw32
Configured with: ../gcc-trunk/configure --prefix=/mingw
--enable-languages=c,for
tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror
--enable-threa
ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --enable-shared
--disa
ble-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto
Thread model: win32
gcc version 4.8.0 20120319 (experimental) [trunk revision 185521] (GCC)

The result is that the ICE is still there. There are just two changes. First,
there are some more warnings, and second, the ICE is reported with a different
line number within GCC source: tree-data-ref.c:1964.

[Bug fortran/52621] ICE when compiling Fortran77 code with optimization

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-03-21 13:12:51 UTC ---
On x86_64-apple-darwin10, the code compiles with the options in comment #0
(with a lot of warnings) for 4.4.6, 4.5.3, 4.6.3, 4.7.0RC2, and trunk (with
-m32 or -m64). So the problem looks mingw32 specific.

[Bug middle-end/52621] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
          Component|fortran                     |middle-end
            Summary|ICE when compiling          |ICE with -O3 -march=opteron
                   |Fortran77 code with         |in initialize_matrix_A, at
                   |optimization                |tree-data-ref.c:1964
      Known to fail|                            |4.6.1, 4.8.0

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-21 13:29:44 UTC ---
I can reproduce it on x86-64-gnu-linux with:
  gfortran -march=opteron -O3 -w -c file.f

The crucial flag is the "opteron" - it works with "core2".

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.4.6, 4.5.3
            Summary|ICE with -O3 -march=opteron |[4.6/4.7/4.8 Regression]
                   |in initialize_matrix_A, at  |ICE with -O3 -march=opteron
                   |tree-data-ref.c:1964        |in initialize_matrix_A, at
                   |                            |tree-data-ref.c:1964

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-03-21 13:50:34 UTC ---
> I can reproduce it on x86-64-gnu-linux with:
>   gfortran -march=opteron -O3 -w -c file.f
>
> The crucial flag is the "opteron" - it works with "core2".

Confirmed. AFAICT the code compiles with 4.4.6 and 4.5.3 (so marked as a
regression) and on trunk when compiled with '-march=opteron -O2
-ftree-vectorize'.

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-03-21
     Ever Confirmed|0                           |1

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-03-21 13:59:09 UTC ---
r162456 is OK
r163718 gives the ICE.

The usual '-fno-whole-file -fno-realloc-lhs' trick does not fix the problem.

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-03-21 14:22:49 UTC ---
Reduced test


      SUBROUTINE GHDSYM(IZ,IS,LMMAX,S,LMS,Y,L2M,DRL,NLAY2,K0,DCUT)!,
!
      COMPLEX Y(L2M,L2M),H(33),S(LMS)
      COMPLEX RU,CI,CZ,K0,FF,Z,Z1,Z2,Z3,ST
!
      DO 140 KK=1,4
            DO 130 L=1,L2M
               L1=L*L-L
               DO 120 M=1,L
                  IPM=L1+M
                  IMM=L1-M+2
                  S(IPM)=S(IPM)+Z3*Y(L,M)
                  IF (M.NE.1) S(IMM)=S(IMM)+Z3*Y(M-1,L)*CSGN
120            CONTINUE
130         CONTINUE
140   CONTINUE
      END

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.6.4
      Known to fail|                            |4.7.0

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-05 10:51:00 UTC ---
Confirmed on x86_64-unknown-linux-gnu with -O2 -fprefetch-loop-arrays.

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spop at gcc dot gnu.org

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-05 11:27:02 UTC ---
evolution_function_is_univariate_p returns true for

{(integer(kind=8)) {0, +, {2, +, 2}_2}_2, +, 1}_3

but that does not look univariate to me - we do not properly look into
CHREC_LEFT which is (integer(kind=8)) {0, +, {2, +, 2}_2}_2, so something
like

@@ -1114,6 +1132,8 @@ evolution_function_is_univariate_p (cons
          break;

        default:
+         if (tree_contains_chrecs (CHREC_LEFT (chrec), NULL))
+           return false;
          break;
        }

@@ -1127,6 +1147,8 @@ evolution_function_is_univariate_p (cons
          break;

        default:
+         if (tree_contains_chrecs (CHREC_RIGHT (chrec), NULL))
+           return false;
          break;
        }

fixes this.  Then we ICE the same way in analyze_miv_subscript because
we think that beast is affine-multivariate.

The above fix looks obvious to me, but what the right condition for
failing in analyze_overlapping_iterations should be for "loop_nest"
should be, and why using the loop number of the outermost loop of the
nest should be sufficient is beyond my understanding.

Sebastian, can you help?  I can certainly amend

  /* If they aren't the same, and aren't affine, we can't do anything
     yet.  */
  else if ((chrec_contains_symbols (chrec_a)
            || chrec_contains_symbols (chrec_b))
           && (!evolution_function_is_affine_multivariate_p (chrec_a, lnn)
               || !evolution_function_is_affine_multivariate_p (chrec_b, lnn)))
    {
      dependence_stats.num_subscript_undetermined++;
      *overlap_iterations_a = conflict_fn_not_known ();
      *overlap_iterations_b = conflict_fn_not_known ();
    }

though it looks to me that this should go into the else part and
the analyze_miv_subscript case lacks a proper test.

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 12:17:12 UTC ---
evolution_function_is_invariant_rec_p returns true for
(integer(kind=8)) {0, +, {2, +, 2}_2}_2 and loop 1 even if loop 2 is nested
inside loop 1.  Thus,

@@ -1011,6 +1029,8 @@ evolution_function_is_invariant_rec_p (t
   if (TREE_CODE (chrec) == POLYNOMIAL_CHREC)
     {
       if (CHREC_VARIABLE (chrec) == (unsigned) loopnum
+         || flow_loop_nested_p (get_loop (loopnum),
+                                get_loop (CHREC_VARIABLE (chrec)))
          || !evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
                                                     loopnum)
          || !evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec),

is required, IMHO, too.

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 14:04:23 UTC ---
Author: rguenth
Date: Wed Apr 11 14:04:00 2012
New Revision: 186321

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186321
Log:
2012-04-11  Richard Guenther  <rguenther@suse.de>

    PR middle-end/52621
    * tree-chrec.c (evolution_function_is_invariant_rec_p): Properly
    consider loop nesting.
    (evolution_function_is_univariate_p): Properly check the remainder
    for chrecs.

    * gfortran.dg/pr52621.f90: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr52621.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-chrec.c

[Bug middle-end/52621] [4.6/4.7 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.8.0
            Summary|[4.6/4.7/4.8 Regression]    |[4.6/4.7 Regression] ICE
                   |ICE with -O3 -march=opteron |with -O3 -march=opteron in
                   |in initialize_matrix_A, at  |initialize_matrix_A, at
                   |tree-data-ref.c:1964        |tree-data-ref.c:1964
      Known to fail|4.8.0                       |

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 14:20:13 UTC ---
Fixed on trunk sofar.

[Bug middle-end/52621] [4.6/4.7 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug middle-end/52621] [4.6/4.7 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-06 09:20:25 UTC ---
Author: rguenth
Date: Fri Jul  6 09:20:19 2012
New Revision: 189312

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189312
Log:
2012-07-06  Richard Guenther  <rguenther@suse.de>

        Backport from mainline
    2012-04-11  Richard Guenther  <rguenther@suse.de>

    PR middle-end/52621
    * tree-chrec.c (evolution_function_is_invariant_rec_p): Properly
    consider loop nesting.
    (evolution_function_is_univariate_p): Properly check the remainder
    for chrecs.

    * gfortran.dg/pr52621.f90: New testcase.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/pr52621.f90
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_7-branch/gcc/tree-chrec.c

[Bug middle-end/52621] [4.6 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.7.2
            Summary|[4.6/4.7 Regression] ICE    |[4.6 Regression] ICE with
                   |with -O3 -march=opteron in  |-O3 -march=opteron in
                   |initialize_matrix_A, at     |initialize_matrix_A, at
                   |tree-data-ref.c:1964        |tree-data-ref.c:1964
      Known to fail|4.6.1, 4.7.0                |4.6.3, 4.7.1

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-06 09:27:02 UTC ---
And for 4.7.2.

[Bug middle-end/52621] [4.6 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #16 from John David Anglin <danglin at gcc dot gnu.org> 2012-07-17 22:56:00 UTC ---
"-fprefetch-loop-arrays" is not supported on 4.7 branch on
hppa2.0w-hp-hpux11.11 and probably other targets:

spawn /mnt/gnu/gcc/objdir-test/gcc/testsuite/gfortran/../../gfortran
-B/mnt/gnu/
gcc/objdir-test/gcc/testsuite/gfortran/../../
-B/mnt/gnu/gcc/objdir-test/hppa2.0
w-hp-hpux11.11/./libgfortran/
/mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/pr52621
.f90 -O -O2 -fprefetch-loop-arrays -S -o pr52621.s
f951: warning: -fprefetch-loop-arrays not supported for this target (try -march 
switches) [enabled by default]

[Bug middle-end/52621] [4.6 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.6.4                       |4.7.2

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 16:27:42 UTC ---
The 4.6 branch has been closed, fixed in GCC 4.7.2.