The capacita benchmark, part of the polyhedron benchmark suite, fails with the ICE in the summary. BT: #0 0x080d0276 in is_gimple_reg_type (type=0x0) at ../../trunk/gcc/tree-gimple.c:269 #1 0x080d0519 in is_gimple_val (t=0xb7852fa4) at ../../trunk/gcc/tree-gimple.c:368 #2 0x083e60c0 in verify_expr (tp=0xb7ba5728, walk_subtrees=0xbfa13e08, data=0x0) at ../../trunk/gcc/tree-cfg.c:3469 #3 0x08363911 in walk_tree (tp=0xb7ba5728, func=0x83e5c20 <verify_expr>, data=0x0, pset=0x0) at ../../trunk/gcc/tree.c:7306 #4 0x083ed9f7 in verify_stmts () at ../../trunk/gcc/tree-cfg.c:3506 #5 0x083ff8c9 in verify_ssa (check_modified_stmt=1 '\001') at ../../trunk/gcc/tree-ssa.c:643 #6 0x0837f1ca in execute_todo (flags=8375) at ../../trunk/gcc/passes.c:794 #7 0x0837f42a in execute_one_pass (pass=0x8690d48) at ../../trunk/gcc/passes.c:884 #8 0x0837f587 in execute_pass_list (pass=0x8690d48) at ../../trunk/gcc/passes.c:909 #9 0x0837f59b in execute_pass_list (pass=0x85cea00) at ../../trunk/gcc/passes.c:910 #10 0x080cfb93 in tree_rest_of_compilation (fndecl=0xb7b4ce80) at ../../trunk/gcc/tree-optimize.c:418 #11 0x083cc8b2 in cgraph_expand_function (node=0xb7b53a80) at ../../trunk/gcc/cgraphunit.c:1102 #12 0x083cdccb in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1167 #13 0x0809ce2f in gfc_be_parse_file (set_yydebug=0) at ../../trunk/gcc/fortran/f95-lang.c:302 #14 0x08350676 in toplev_main (argc=3, argv=0xbfa14084) at ../../trunk/gcc/toplev.c:999 #15 0xb7d9dea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #16 0x0804af01 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) up 7 #7 0x0837f42a in execute_one_pass (pass=0x8690d48) at ../../trunk/gcc/passes.c:884 884 execute_todo (todo_after | pass->todo_flags_finish); (gdb) print *pass $1 = {name = 0x85acd37 "phicprop", gate = 0x8428830 <gate_dominator>, execute = 0x842adc0 <eliminate_degenerate_phis>, sub = 0x0, next = 0x85dc900, static_pass_number = 58, tv_id = 43, properties_required = 584, properties_provided = 0, properties_destroyed = 2048, todo_flags_start = 0, todo_flags_finish = 8375, letter = 0 '\0'} Undisclosed sources on IRC tell me that this bug is due to the new pass Jeff has contributed.
Created attachment 11097 [details] Testcase Testcase that demonstrates the ICE.
Confirmed, shorter testcase: module solv_cap integer, private, save :: Ng1=0, Ng2=0 contains subroutine FourirG(G) real, intent(in out), dimension(0:,0:) :: G complex, allocatable, dimension(:,:) :: t allocate( t(0:2*Ng1-1,0:2*Ng2-1) ) t(0:Ng1,0:Ng2-1) = G(:,0:Ng2-1) ! Fill one quadrant (one extra row) t(0:Ng1,Ng2:2*Ng2-1) = G(:,Ng2:1:-1) ! This quadrant using symmetry end subroutine FourirG end module solv_cap
Subject: Re: [4.2 Regression] ICE at gcc/tree-gimple.c:269 On Wed, 2006-03-22 at 17:27 +0000, pinskia at gcc dot gnu dot org wrote: > > ------- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-22 17:27 ------- > Confirmed, shorter testcase: > module solv_cap > integer, private, save :: Ng1=0, Ng2=0 > contains > subroutine FourirG(G) > real, intent(in out), dimension(0:,0:) :: G > complex, allocatable, dimension(:,:) :: t > allocate( t(0:2*Ng1-1,0:2*Ng2-1) ) > t(0:Ng1,0:Ng2-1) = G(:,0:Ng2-1) ! Fill one quadrant (one extra row) > t(0:Ng1,Ng2:2*Ng2-1) = G(:,Ng2:1:-1) ! This quadrant using symmetry > end subroutine FourirG > end module Options/flags? I've been unable to reproduce this. jeff
(In reply to comment #3) > Options/flags? I've been unable to reproduce this. Just -O2.
I see a similar failure in galgel on Diego's testers: /home/cygnus/dnovillo/perf/sbox/gcc/local.i686/inst.tobiano/bin/gfortran -c -o bifgel.o -ffixed-form -ffloat-store -O2 -march=pentium4 -mtune=generic bifgel.f90 Error from make 'specmake build 2> make.err | tee make.out': bifgel.f90: In function 'bifgel': bifgel.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. But I cannot reduce that or debug that because I don't have the source to SPEC.
Well we get a SSA_NAME in the free list: <ssa_name 0x2aaaab13a690 nothrow var <var_decl 0x2aaaab123e70 ng2.13> def_stmt <ssa_name 0x2aaaab132a80> version 66 in-free-list>
The statement is: D.939_75 = ng2.13D.965_8 + ng2.13D.965_66 Oh, before we had: D.939_75 = ng2.13_66 + ng2.13_66; Looks like phicprop does not replace both ng2.13_66.
The only thing I can think of what is causing this is the replacement is causing the use info to go bad as there are two uses in this one statement.
Subject: Re: [4.2 Regression] ICE at gcc/tree-gimple.c:269 On Thu, 2006-03-23 at 00:09 +0000, pinskia at gcc dot gnu dot org wrote: > > ------- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-23 00:09 ------- > I see a similar failure in galgel on Diego's testers: > /home/cygnus/dnovillo/perf/sbox/gcc/local.i686/inst.tobiano/bin/gfortran -c -o > bifgel.o -ffixed-form -ffloat-store -O2 -march=pentium4 > -mtune=generic bifgel.f90 > Error from make 'specmake build 2> make.err | tee make.out': > bifgel.f90: In function 'bifgel': > bifgel.f90:1: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. > > But I cannot reduce that or debug that because I don't have the source to SPEC. This is arguably a bug in the code to walk immediate uses; if a statement has multiple uses of the same SSA_NAME and you modify the statement during the imm-uses walk, there are cases where the imm-uses walk will miss the second use within the statement. The net result in this particular case is we fail to propagate away a use (because it wasn't visited due to the bug noted above), we then proceed to remove the SSA_NAME (as all its uses should have been removed). Andrew is aware of the problem and we kicked around some ideas for how to resolve it long term. I've got a couple of short-term workarounds that I'm testing. jeff
*** Bug 26832 has been marked as a duplicate of this bug. ***
*** Bug 26833 has been marked as a duplicate of this bug. ***
Subject: Re: New: ICE at gcc/tree-gimple.c:269 On Wed, 2006-03-22 at 16:47 +0000, jb at gcc dot gnu dot org wrote: > The capacita benchmark, part of the polyhedron benchmark suite, fails with the > ICE in the summary. BT: [ ... ] The root cause of this problem is the immediate-use iterators not visiting an immediate use in certain circumstances. Andrew and I have discussed this a little and Andrew thinks he may be able to fix the iterator -- however, that's not likely to happen until he returns from some travel. In the mean time this change works around the immediate-use iterator problem. Basically we re-start the iterator if we have an LHS which we expect to have no uses, but which still has immediate uses after the iterator exits. [ The first version actually split the loop into two phases one to propagate into all uses, the other to fold and simplify statements after propagation. That works. But this is much simpler. ] This fixes pr26806 and pr26833. Bootstrapped and regression tested on i686-pc-linux-gnu.
Created attachment 11109 [details] PPP
*** Bug 26836 has been marked as a duplicate of this bug. ***
re this PR 26806 and PR 26833 (judged equivalent) the yasm--0.4.0 referred to in PR 26833 compiled OK with the temporary fix and passed an extensive battery of tests included in yasm-0.4.0. Documentation issues (irrelevant to GCC) were faked out.
Fixed a couple weeks ago.