[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #14 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-02-05 10:35:28 UTC --- Author: tkoenig Date: Sat Feb 5 10:35:24 2011 New Revision: 169850 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169850 Log: 2001-02-05 Thomas Koenig tkoe...@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
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #15 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-02-05 10:39:07 UTC --- Test case committed to trunk, closing.
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574
--- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr
2011-02-03 20:16:40 UTC ---
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?
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #6 from Martin Losch mlo...@uni-bremen.de 2011-02-02 09:00:10 UTC --- (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?
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #7 from Martin Losch mlo...@uni-bremen.de 2011-02-02 09:09:07 UTC --- (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.
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-02 09:35:31 UTC --- (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. 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 there are only two COMMONs: /EEPARAMS_L/ and /EEPARAMS_I/).
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Martin Losch mlo...@uni-bremen.de changed: What|Removed |Added Attachment #23201|0 |1 is obsolete|| --- Comment #9 from Martin Losch mlo...@uni-bremen.de 2011-02-02 10:08:39 UTC --- Created attachment 23212 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23212 simplified fortran code to reproduce problem commenting either lines 91 and 92 or 98 and 99 gets rid off the ICE
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #10 from Martin Losch mlo...@uni-bremen.de 2011-02-02 10:28:15 UTC --- (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).
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-02 11:22:39 UTC --- 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.
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-02 16:25:42 UTC --- This pr looks like a duplicate of pr46664 fixed at revision 167173 (the test in attachment 23212 gives an ICE also at revision 167138).
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Martin Losch mlo...@uni-bremen.de changed: What|Removed |Added Attachment #23200|0 |1 is obsolete|| --- Comment #1 from Martin Losch mlo...@uni-bremen.de 2011-02-01 16:20:19 UTC --- Created attachment 23201 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23201 correct fortran code to reproduce problem I am sorry for attaching the wrong file
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 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 2011-02-01 16:46:42 UTC --- 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?
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #3 from Martin Losch mlo...@uni-bremen.de 2011-02-01 17:30:56 UTC --- 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?
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-01 18:32:44 UTC --- 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?
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-01 18:59:25 UTC --- 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?
