Attached preprocessed file from the linux 2.6 kernel makes the compiler ICE: Program received signal SIGSEGV, Segmentation fault. register_new_def (def=0x2a966447e0, block_defs_p=0xb106f8) at tree-flow-inline.h:32 32 { #0 register_new_def (def=0x2a966447e0, block_defs_p=0xb106f8) at tree-flow-inline.h:32 #1 0x000000000047abe4 in optimize_stmt (walk_data=0x7fbfffc230, bb=0x2a9667f7e0, si= {tsi = {ptr = 0x2a9667ac60, container = 0x2a9667f540}, bb = 0x0}) at tree-flow-inline.h:275 #2 0x000000000047d5c6 in walk_dominator_tree (walk_data=0x7fbfffc230, bb=0x2a9667f7e0) at /averell/src/src/gcc-head/gcc/gcc/domwalk.c:189 #3 0x000000000047d3c9 in walk_dominator_tree (walk_data=0x7fbfffc230, bb=0x2a9667f540) at /averell/src/src/gcc-head/gcc/gcc/domwalk.c:205 #4 0x000000000047d3c9 in walk_dominator_tree (walk_data=0x7fbfffc230, bb=0x2a9667f1c0) at /averell/src/src/gcc-head/gcc/gcc/domwalk.c:205 #5 0x000000000047c81c in tree_ssa_dominator_optimize () gcc version 3.5.0 20040708 (experimental) Compile with cc1 -m32 -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -msoft-float -mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=i686 -mregparm=3 -Os -g -Wdeclaration-after-statement
Created attachment 6714 [details] preprocessed test case
I cannot reproduce it on i686-linux-gnu
Perhaps it needs a x86-64 host to trigger. Can someone else try that with a 64bit host? Also the compiler was compiled with --disable-checking (maybe that makes a difference). I saw it several times at the same location so it wasn't flakey memory or somesuch.
I played a bit with the options and -m32 -Os -fno-unit-at-a-time gives a ICE too, at a slightly different place but with the same cause: gss_mech_svc_setup Program received signal SIGSEGV, Segmentation fault. 0x00000000004802e3 in get_phi_state (var=0xc1a7e0) at ../../gcc/gcc/tree-into-ssa.c:165 165 return var_ann (var)->need_phi_state; (gdb) bt #0 0x00000000004802e3 in get_phi_state (var=0xc1a7e0) at ../../gcc/gcc/tree-into-ssa.c:165 #1 0x000000000047ebde in register_new_def (def=0x2a9644c380, block_defs_p=0xc24e38) at ../../gcc/gcc/tree-into-ssa.c:1363 #2 0x00000000004a9603 in register_definitions_for_stmt (ann=0x2a9647f900, block_defs_p=0xc24e38) at ../../gcc/gcc/tree-ssa-dom.c:3684 #3 0x00000000004a87f2 in optimize_stmt (walk_data=0x7fbfffdd40, bb=0x2a9647da80, si= {tsi = {ptr = 0x2a96476bc0, container = 0x2a9647c270}, bb = 0x2a9647da80}) at ../../gcc/gcc/tree-ssa-dom.c:3117 #4 0x00000000004a9d60 in walk_dominator_tree (walk_data=0x7fbfffdd40, bb=0x2a9647da80) at ../../gcc/gcc/domwalk.c:189 var_ann returns a bogus pointer: (gdb) p var_ann(var) $1 = (struct var_ann_d *) 0x5f7373672f737367 Someone corrupted var->common.ann. 0x5f7373672f737367 is ASCII gss/gss_, which is a common prefix used in identifiers in the file
Can you provide the output of compiling after adding -v as this might be a GC related problem which is why I cannot reproduce it on my machine with the GC params for my machine.
Here's a reduced testcase that crashes mainline (with checking enabled) on i686-pc-linux-gnu. Just compile with -Os: ================================== void foo(char *p) { __asm__ ("" ::: "memory"); } void bar() { static char *p; foo(p); } ================================== The error message is: PR16443.c: In function `bar': PR16443.c:7: error: Expected an SSA_NAME object p<D1122> # p<D1122> = V_MAY_DEF <p<D1122>>; __asm__("":::"memory"); PR16443.c:7: internal compiler error: tree check: expected ssa_name, have var_decl in verify_def, at tree-ssa.c:126 Please submit a full bug report, [etc.]
Hmm, are you sure your testcase is the same bug? I didn't see an error, just internal memory corruption in the compiler.
It's a tree checking failure. So a) You won't see the error message, because you disabled checking. b) The tree structure is corrupted somehow. Often you end up with a segfault later when the compiler tries to dereference something that is not a properly initialized pointer. So chances are high that this is really the underlying bug.
Diego, it looks like your patch http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00349.html is responsible for the regression. Could you please have a look?
Hi, the following part from the patch identified by Volker looks very suspicious: + EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, i, + { + tree var = referenced_var (i); + add_stmt_operand (&var, stmt, opf_is_def, prev_vops); + }); We're passing the address of a local var down to add_stmt_operand. add_stmt_operand will add this _address_, i.e. &var to the statement operands. This is bound to fail as soon as we leave the scope of var. The following might be a temporary solution: Index: tree-ssa-operands.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/tree-ssa-operands.c,v retrieving revision 2.15 diff -u -r2.15 tree-ssa-operands.c --- tree-ssa-operands.c 8 Jul 2004 15:03:10 -0000 2.15 +++ tree-ssa-operands.c 13 Jul 2004 15:08:53 -0000 @@ -1229,36 +1229,7 @@ for (link = ASM_CLOBBERS (stmt); link; link = TREE_CHAIN (link)) if (strcmp (TREE_STRING_POINTER (TREE_VALUE (link)), "memory") == 0) { - size_t i; - - /* If we still have not computed aliasing information, we - won't know what variables are call-clobbered and/or - addressable. Just mark the statement as having volatile - operands for now. */ - if (!aliases_computed_p) - { - stmt_ann (stmt)->has_volatile_ops = true; - break; - } - - /* Clobber all call-clobbered variables (or .GLOBAL_VAR if we - decided to group them). */ - if (global_var) - add_stmt_operand (&global_var, stmt, opf_is_def, prev_vops); - else - EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, i, - { - tree var = referenced_var (i); - add_stmt_operand (&var, stmt, opf_is_def, prev_vops); - }); - - /* Now clobber all addressables. */ - EXECUTE_IF_SET_IN_BITMAP (addressable_vars, 0, i, - { - tree var = referenced_var (i); - add_stmt_operand (&var, stmt, opf_is_def, prev_vops); - }); - + stmt_ann (stmt)->has_volatile_ops = true; break; } } regards Christian
Subject: Re: [3.5 Regression] ICE during linux kernel compilation On Tue, 2004-07-13 at 11:16, ehrhardt at mathematik dot uni-ulm dot de wrote: > the following part from the patch identified by Volker looks > very suspicious: > > + EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, i, > + { > + tree var = referenced_var (i); > + add_stmt_operand (&var, stmt, opf_is_def, prev_vops); > + }); > > We're passing the address of a local var down to add_stmt_operand. > add_stmt_operand will add this _address_, i.e. &var to the statement > operands. This is bound to fail as soon as we leave the scope of var. > Not really. We are adding virtual definitions in this code, we don't add &var, we add var. We only need the address when adding real operands. I will agree that this is not a really good interface, but add_stmt_operand is a local function. > The following might be a temporary solution: > Here you just papered over the whole bug :) Diego.
Testing patch.
Subject: Bug 16443 CVSROOT: /cvs/gcc Module name: gcc Changes by: dnovillo@gcc.gnu.org 2004-07-13 20:51:03 Modified files: gcc : ChangeLog tree-ssa-alias.c tree-ssa-operands.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: 20040713-1.c Log message: PR tree-optimization/16443 * tree-ssa-alias.c: Add more description for CALL_CLOBBERED_VARS and ADDRESSABLE_VARS. * tree-ssa-operands.c (get_asm_expr_operands): Re-order the clobbering of call-clobbered and addressable variables. If there are any before aliases have been computed, add them. testsuite/ChangeLog PR tree-optimization/16443 * gcc.dg/tree-ssa/20040713-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.4509&r2=2.4510 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcc&r1=2.10&r2=2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-operands.c.diff?cvsroot=gcc&r1=2.15&r2=2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3996&r2=1.3997 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/20040713-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed.
I can confirm that the patch fixes the big test case on x86-64 too. Thanks.