Created attachment 23201 [details]
correct fortran code to reproduce problem

I am sorry for attaching the wrong file

Works for me on x86-64-linux. There is some possibility that the patch for PR 45700 fixed that issue (committed: 2010-11-26) - at least that is the only thing which vaguely goes into the direction of the ICE (internal compiler error).

Thus, one possibility would be to try a newer version.

Other than that:

gfortran -v -save-temps -Wunused -Wuninitialized -fsecond-underscore
-fconvert=big-endian -ffixed-line-length-132 -O3 -funroll-loops -c

You use a large number of options. Can you cut down the number of options and see whether, e.g., -O2 or -O1 or -O0 is enough to trigger the issue?

gfortran -O3 -c exch2_uv_agrid_3d_rl.f
gives the same error

gfortran -O2 -c exch2_uv_agrid_3d_rl.f
works for this file (for others that are similar I need -O1).

I have to admit that I have never ventured into building gfortran/gcc myself, but downloaded the binaries for Mac OS X 10.6 here: <http://hpc.sourceforge.net/>. I just posted this bug, because I thought it would be useful. If my rebuilding gfortran from source is required I won't be of much help.

(In reply to comment #2)
> Works for me on x86-64-linux. There is some possibility that the patch for PR
> 45700 fixed that issue (committed: 2010-11-26) - at least that is the only
> thing which vaguely goes into the direction of the ICE (internal compiler
> error).
> 
> Thus, one possibility would be to try a newer version.
> 
> Other than that:
> 
> gfortran -v -save-temps -Wunused -Wuninitialized -fsecond-underscore
> -fconvert=big-endian -ffixed-line-length-132 -O3 -funroll-loops -c
> 
> You use a large number of options. Can you cut down the number of options and
> see whether, e.g., -O2 or -O1 or -O0 is enough to trigger the issue?

I cannot reproduce it on x86_64-apple-darwin10 with all the options/versions I have tried (including gcc version 4.6.0 20101106 (experimental) [trunk revision 166401]).

One possibility could be a miscompilation due to gmp/mpfr/mpc: I use

GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2

Do you know a minimal use of gdb?

I have had a look at the test code. Could you try 

(1) to comment the call to EXCH2_UV_AGRID_3D_RL,
(2) the same for the (two?) COMMONs,

and see if one of these changes makes the ICE disappear?

(In reply to comment #4)
As far as I can see (from the header files that came with pre-compiled binaries) this was used:
#define MPFR_VERSION_STRING "2.4.1"

#define MPC_VERSION_STRING "0.8.1"

#define __GNU_MP_VERSION 4
#define __GNU_MP_VERSION_MINOR 3
#define __GNU_MP_VERSION_PATCHLEVEL 1

I have used gdb for minimally, but what is its use here? I cannot create an executable if I do not reduce the optimization level. What do you suggest?

(In reply to comment #5)
> I have had a look at the test code. Could you try 
> 
> (1) to comment the call to EXCH2_UV_AGRID_3D_RL,
> (2) the same for the (two?) COMMONs,
> 
> and see if one of these changes makes the ICE disappear?

I do not understand (1): commenting out the call to this routine elsewhere does not modify the compilation of the routine. If you meant commenting out the calls to EXCH2_RL1_CUBE, then this does not make the ICE go away.
(2) I commented out all (five) COMMON blocks (but not the associated declarations of variables), and the ICE does not go away, either. 

What makes the problem go away is commenting out line 949.

(In reply to comment #6)
> I have used gdb for minimally, but what is its use here? I cannot create an
> executable if I do not reduce the optimization level. What do you suggest?

I suggest to run gdb on f951 to see the path leading to the error

exch2_uv_agrid_3d_rl.f:293:0: internal compiler error: in build2_stat, at
tree.c:3795

gfortran is located in /some_path/bin. You'll find f951 in /some_path/libexec/gcc/platform/version/

(gdb /opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/f951 for me).

Set a breakpoint to fancy_abort, run the code and do a backtrace.

(In reply to comment #7)
> What makes the problem go away is commenting out line 949.

There is no line 949 in attachment 23201 [details]. The goal is to reduce the file to the "minimal" size reproducing the ICE. CALL and COMMON have triggered bugs in the past, hence my question (note that in the attachment 23201 [details] there are only two COMMONs: /EEPARAMS_L/ and /EEPARAMS_I/).

Created attachment 23212 [details]
simplified fortran code to reproduce problem

commenting either lines 91 and 92 or 98 and 99 gets rid off the ICE

(In reply to comment #8)
> (In reply to comment #6)
> > I have used gdb for minimally, but what is its use here? I cannot create an
> > executable if I do not reduce the optimization level. What do you suggest?
> 
> I suggest to run gdb on f951 to see the path leading to the error
> 
> exch2_uv_agrid_3d_rl.f:293:0: internal compiler error: in build2_stat, at
> tree.c:3795
> 
> gfortran is located in /some_path/bin. You'll find f951 in
> /some_path/libexec/gcc/platform/version/
> 
> (gdb /opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/f951 for me).
> 
> Set a breakpoint to fancy_abort, run the code and do a backtrace.

I am afraid that's beyond my capabilities. my gdb does not off a breakpoint fancy_abort and since I only download precompiled binaries the gbd does not even find the object files. Here's the beginning of the output:

>gdb /usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951
GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...
warning: Could not find object file "/Users/gkhanna/build/x86_64-apple-darwin10.4.0/libgcc/_muldi3_s.o" - no debug information available for "../../../gcc-4.6-20101106/libgcc/../gcc/libgcc2.c".

[...]
> 
> (In reply to comment #7)
> > What makes the problem go away is commenting out line 949.
> 
> There is no line 949 in attachment 23201 [details]. The goal is to reduce the file to the
> "minimal" size reproducing the ICE. CALL and COMMON have triggered bugs in the
> past, hence my question (note that in the attachment 23201 [details] there are only two
> COMMONs: /EEPARAMS_L/ and /EEPARAMS_I/).

This is embarrissing. I apologize for attaching another wrong file (the correct file name would have been exch2_uv_agrid_3d_rl.f). I have now removed everything from this file that seems unnecessary to reproduce the ICE and have attached it as strippeddownfile.f (attachment 23212 [details]).

> This is embarrissing. I apologize for attaching another wrong file (the correct
> file name would have been exch2_uv_agrid_3d_rl.f). I have now removed
> everything from this file that seems unnecessary to reproduce the ICE and have
> attached it as strippeddownfile.f (attachment 23212 [details]).

Now I can reproduce it with revisions 166102, 166367, 166401, 166533, and 167096, but not with revision 162456 nor revision 167584.

So the bug seems to have been introduced between revisions 162456 and 166102 and fixed between revisions 167096 and 167584. You are unlucky to be right where the bug is;-(I'll look later to see if I can refine the windows and try to spot the right pr). Meanwhile you should notify Gaurav Khanna about the bug and ask him if he his planning a more recent build.

This pr looks like a duplicate of pr46664 fixed at revision 167173 (the test in attachment 23212 [details] gives an ICE also at revision 167138).

Further reduced test case

! { dg-do compile }
      SUBROUTINE EXCH2_UV_AGRID_3D_RL( uPhi, vPhi, myNz )

      IMPLICIT NONE

      INTEGER, parameter :: sNx=32, sNy=32, OLx=4, OLy=4

      INTEGER myNz
      Real*8 uPhi(1-OLx:sNx+OLx,1-OLy:sNy+OLy,myNz,3,1)
      Real*8 vPhi(1-OLx:sNx+OLx,1-OLy:sNy+OLy,myNz,3,1)

      INTEGER i,j,k,bi,bj
      Real*8 uLoc(1-OLx:sNx+OLx,1-OLy:sNy+OLy)
      Real*8 vLoc(1-OLx:sNx+OLx,1-OLy:sNy+OLy)
      Real*8 negOne

      negOne = 1.
        DO k = 1,myNz
         DO j = 1-OLy,sNy+OLy
          DO i = 1-OLx,sNx+OLx
           uLoc(i,j) = uPhi(i,j,k,bi,bj)
           vLoc(i,j) = vPhi(i,j,k,bi,bj)
          ENDDO
         ENDDO
         DO j = 1-OLy,sNy+OLy
          DO i = 1,OLx
           uPhi(1-i,j,k,bi,bj) = vLoc(1-i,j)
           vPhi(1-i,j,k,bi,bj) = uLoc(1-i,j)*negOne
          ENDDO
         ENDDO
         
        ENDDO
      
      END

It gives an ICE at revision 167172, but not at revision 167173, hence a duplicate of pr46664. Note that revision 167173 did not add a test case. Should not the above test be added to the test suite before I close this PR as a duplicate?

Author: tkoenig
Date: Sat Feb  5 10:35:24 2011
New Revision: 169850

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169850
Log:
2001-02-05  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/47574
	* gfortran.dg/pr47574.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr47574.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

Test case committed to trunk, closing.