This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Trying to compile the espresso electronic structure package from pwscf.org with gfortran 4.1.1 fails with an ICE: make[1]: Entering directory `/home/donnie/espresso-3.1/Modules' cpp -P -traditional -D__FFTW -I../include constraints_module.f90 -o constraints_module.F90 gfortran -O3 -D__FFTW -I../include -I. -I../Modules -I../PW -I../PH -I../iotk/src -I../CPV -c constraints_module.F90 -o constraints_module.o constraints_module.F90: In function 'set_structure_factor': constraints_module.F90:304: internal compiler error: in find_lattice_value, at tree-complex.c:133 Interestingly, this ICE only occurs at optimization levels greater than -O0. I've uploaded constraints_module.F90 and the required *.mod files to http://dev.gentoo.org/~spyderous/espresso-ice.tar.bz2 to assist in fixing this.
I can reproduce this on i686-linux and reduced it to this minimal testcase: COMPLEX z CONTAINS SUBROUTINE foo z = z + cmplx(1.0,0.0) z = z + z END SUBROUTINE foo END It fails for me at all optimization levels, including -O0. I've tried it with current mainline as well as mainline from 2006-05-01, it exhibits the same errors. I can't make a C testcase easily, but I think it's a middle-end issue because the same testcase compiled on 4.1.2 works, although it gives the same tree (with -fdump-original-tree): foo () { z = z + __complex__ (1.0e+0, 0.0); z = z + z; MAIN__ () { complex4 z; static void foo (void); _gfortran_set_std (70, 127, 0); }
I now also have a slightly different testcase that fails on 4.1.1 and current 4.1 branch, on i686-linux, at optimization levels -O1 or higher: MODULE constraints_module REAL target CONTAINS SUBROUTINE init_constraint COMPLEX struc_fac CALL set_structure_factor RETURN CONTAINS SUBROUTINE set_structure_factor target = CONJG( struc_fac ) * struc_fac END SUBROUTINE set_structure_factor END SUBROUTINE init_constraint END MODULE constraints_module Paul, I'm adding you to the CC list since this looks fully module-related.
I examined the different tree dumps for COMPLEX z CONTAINS SUBROUTINE foo z = z + z END SUBROUTINE foo END and the last non-empty one before the error message: complex.f90: In function ‘foo’:complex.f90:4: error: invalid operand to binary operator D.906 complex.f90:4: internal compiler error: verify_stmts failed is complex.f90.021t.eh, which has the following content: ;; Function foo (foo.899) foo () { complex4 D.908; complex4 D.907; complex4 D.906; complex4 z [value-expr: CHAIN.1->z]; D.906 = CHAIN.1->z; D.907 = CHAIN.1->z; D.908 = D.906 + D.907; CHAIN.1->z = D.908; return; }
*** This bug has been marked as a duplicate of 27478 ***
Reopening ...
C testcase: int main(void) { _Complex int x; void f(void) { x = x + x; } }
Subject: RE: ICE on complex assignment FX, > Paul, I'm adding you to the CC list since this looks fully > module-related. > Oh Gee, thanks - that's all I need!...... I'll take a look at it this morning. Paul
(In reply to comment #7) > > Paul, I'm adding you to the CC list since this looks fully > > module-related. > > > > Oh Gee, thanks - that's all I need!...... Look at my C example, it is not related to Fortran at all. :). So you don't need to look into it :).
Subject: RE: [4.1/4.2 Regression] ICE on complex assignment in nested function Andrew, Thanks, I just went at the mail in the wrong order. I discovered that it is not fortran by peaking at the PR. Who knows, maybe I can fix a C bug too? Paul
Noting the non-fortran tilt on this, it is interesting that implicit COMPLEX (a-z) CALL foo CONTAINS SUBROUTINE foo t = s + s END SUBROUTINE foo END is OK and produces declarations for s and t in foo. Alternatively, declaring s and t in foo also works. However, COMPLEX s, t CALL foo CONTAINS SUBROUTINE foo t = s + s END SUBROUTINE foo END puts the declarations in MAIN__, thusly: foo () { t = s + s; MAIN__ () { complex4 s; complex4 t; static void foo (void); _gfortran_set_std (70, 127, 0); foo (); } and triggers the ICE for any optimization level. In fortran parlance, it is host or use association of the complex type that is broken. Paul
(In reply to comment #10) > implicit COMPLEX (a-z) Does that actually declare the variables in MAIN or just say after the first use, they are declared in that function as complex? (this should be noted as a seperate bug if it really should declared the variables in the "program" instead of the function).
(In reply to comment #11) > (In reply to comment #10) > > implicit COMPLEX (a-z) > Does that actually declare the variables in MAIN or just say after the first > use, they are declared in that function as complex? > (this should be noted as a seperate bug if it really should declared the > variables in the "program" instead of the function). They are declared in MAIN and the type information should be host associated to the variables in the function. According to the gfortran parse tree, this is happening correctly: $ /irun/bin/gfortran -fdump-parse-tree pr27889.f90 Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = MAIN__ symtree: t Ambig 0 symbol t (COMPLEX 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC ) symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS INTERNAL- PROC SUBROUTINE) symtree: MAIN__ Ambig 0 symbol MAIN__ (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT PUBLIC UNKNOWN-PROC S UBROUTINE) symtree: s Ambig 0 symbol s (COMPLEX 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC ) CALL foo () CONTAINS Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo symtree: foo Ambig 0 from namespace MAIN__ ASSIGN MAIN__:t (+ MAIN__:s MAIN__:s) pr27889.f90: In function 'foo': pr27889.f90:2: error: invalid operand to binary operator D.907 pr27889.f90:2: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. This is rather like that parameter bug, isn't it, Andrew? ie. type information is not getting correctly broadcast to enclosed procedure blocks. Paul
Janis could you do a regression hunt with the testcase in comment #6?
The problem appears to be that DECL_COMPLEX_GIMPLE_REG_P is not getting set on the declarations correctly. The VAR_DECLs that are operands to the additions don't have DECL_COMPLEX_GIMPLE_REG_P set, so fail the is_gimple_val check in verify_stmts.
Not release-critical until we have evidence that this is not Fortran-specific.
(In reply to comment #15) > Not release-critical until we have evidence that this is not Fortran-specific. Mark, Did you miss comment #6 which shows the bug in C code? Yes there were a lot of comments thinking it was a Fortran specific but I created a C testcase to show it was not.
Yes, I did miss Comment #6. I've reset this to P2, in light of that.
A regression hunt on powerpc-linux using the C testcase from comment #6 identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=100793 r100793 | rth | 2005-06-09 07:43:40 +0000 (Thu, 09 Jun 2005)
Testing patch.
Subject: Bug 27889 Author: rth Date: Tue Jul 18 01:17:52 2006 New Revision: 115541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115541 Log: PR 27889 * tree-nested.c (create_tmp_var_for): Set DECL_COMPLEX_GIMPLE_REG_P if needed. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr27889.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-nested.c
Subject: Bug 27889 Author: rth Date: Thu Jul 20 15:43:44 2006 New Revision: 115621 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115621 Log: PR 27889 * tree-nested.c (create_tmp_var_for): Set DECL_COMPLEX_GIMPLE_REG_P if needed. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr27889.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-nested.c
Fixed.