The linux kernel build on the gcc.opensuse.org base tester currently fails with ./cc1 -quiet sched.i kernel/sched.c: In function 'build_sched_domains': kernel/sched.c:6325: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Program received signal SIGSEGV, Segmentation fault. 0x00000000007caa09 in is_gimple_mem_rhs_or_call (t=0x0) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:633 633 if (is_gimple_reg_type (TREE_TYPE (t))) (gdb) bt #0 0x00000000007caa09 in is_gimple_mem_rhs_or_call (t=0x0) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:633 #1 0x00000000007f7fb0 in gimplify_expr (expr_p=0x7ffff4efb7f8, pre_p=0x7fffffffb648, post_p=0x7fffffff8e28, gimple_test_f=0x7ca9ed <is_gimple_mem_rhs_or_call>, fallback=1) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7159 #2 0x00000000007e4023 in gimplify_modify_expr (expr_p=0x7fffffff9718, pre_p=0x7fffffffb648, post_p=0x7fffffff8e28, want_value=0 '\0') at /space/rguenther/src/svn/trunk/gcc/gimplify.c:4379 #3 0x00000000007f391d in gimplify_expr (expr_p=0x7fffffff9718, pre_p=0x7fffffffb648, post_p=0x7fffffff8e28, gimple_test_f=0x7bff1c <is_gimple_stmt>, fallback=0) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:6516 #4 0x00000000007e8724 in gimplify_stmt (stmt_p=0x7fffffff9718, seq_p=0x7fffffffb648) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:5162 #5 0x00000000007ca161 in gimplify_and_add (t=0x7ffff4efb7c0, seq_p=0x7fffffffb648) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:390 #6 0x00000000007df18b in gimplify_init_ctor_eval (object=0x7ffff4efb240, elts=0x7ffff4ef6200, pre_p=0x7fffffffb648, cleared=1 '\1') at /space/rguenther/src/svn/trunk/gcc/gimplify.c:3490 #7 0x00000000007e0c65 in gimplify_init_constructor (expr_p=0x7ffff4ed8f10, pre_p=0x7fffffffb648, post_p=0x7fffffffa288, want_value=0 '\0', notify_temp_creation=0 '\0')
Reduced testcase, maybe due to the C const expression changes(?) typedef struct { unsigned long bits[(((128)+64 -1)/64)]; } cpumask_t; struct sched_domain { cpumask_t span; int flags; }; void cpu_to_allnodes_group(struct sched_domain *sd, int sched_smt_power_savings) { *sd = (struct sched_domain) { .span = (cpumask_t) { { [0 ... (((128)+64 -1)/64)-1] = 0UL } }, .flags = (sched_smt_power_savings ? 256 : 0), }; }
Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote: > Reduced testcase, maybe due to the C const expression changes(?) I see nothing in the reported information about this bug to suggest this (rather than, say, the move of COMPOUND_LITERAL_EXPR handling to language-independent code). What do you think is wrong about the trees being passed by the C front end to the gimplifier?
Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor On Wed, 6 May 2009, joseph at codesourcery dot com wrote: > Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor > > On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote: > > > Reduced testcase, maybe due to the C const expression changes(?) > > I see nothing in the reported information about this bug to suggest this > (rather than, say, the move of COMPOUND_LITERAL_EXPR handling to > language-independent code). What do you think is wrong about the trees > being passed by the C front end to the gimplifier? It was just wild guessing - the COMPOUND_LITERAL_EXPR changes may be indeed a better guess. Richard.
gimplify_init_constructor does tree ctor = TREE_OPERAND (*expr_p, 1); ... new_ctor = optimize_compound_literals_in_ctor (ctor); elts = CONSTRUCTOR_ELTS (new_ctor); ... gimplify_init_ctor_preeval (&TREE_OPERAND (*expr_p, 1), pre_p, post_p, &preeval_data); (which changes a COND_EXPR to have void type, updating the pointer to that COND_EXPR in TREE_OPERAND (*expr_p, 1) - the old constructor - to point to the gimplifier-generated temorary instead) ... if (!cleared || num_nonzero_elements > 0) gimplify_init_ctor_eval (object, elts, pre_p, cleared); (which goes through the elements of the new constructor, finds the modified COND_EXPR and ends up segfaulting because of that). This looks like the compound literal changes must be responsible and that it is a gimplifier bug.
I have a patch. It's just that TREE_OPERAND (*expr, 1) must be changed to new_ctor.
Created attachment 17850 [details] patch to fix the bug
Subject: Bug 40026 Author: bonzini Date: Mon May 11 16:05:45 2009 New Revision: 147386 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147386 Log: 2009-05-11 Paolo Bonzini <bonzini@gnu.org> PR tree-optimization/40026 * gimplify.c (gimplify_init_constructor): Change initial conditional to assertion. Rewrite TREE_OPERAND (*expr_p, 1) after optimize_compound_literals_in_ctor. testsuite: 2009-05-11 Paolo Bonzini <bonzini@gnu.org> * gcc.c-torture/compile/pr40026.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40026.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
Fixed.