Recent versions of make fail with an error reproducible as follows. $ gcc -O2 -c -o buggy.o buggy.c buggy.c: In function 'pop_variable_scope': buggy.c:62: fatal error: internal consistency failure compilation terminated. Workaround: change -O2 to -O1.
Created attachment 10544 [details] Test Case
Also fails with gcc-4.1 (debian 4.1-0exp4).
Reduced testcase on the mainline: void __attribute__((const)) g(void); struct variable_set{int i;}; struct variable_set_list { struct variable_set_list *next; struct variable_set *set; }; extern struct variable_set_list *current_variable_set_list; static struct variable_set global_variable_set; static struct variable_set_list global_setlist = { 0, &global_variable_set }; void pop_variable_scope (void) { struct variable_set_list *setlist; if (current_variable_set_list->next == 0) g(); if (current_variable_set_list != &global_setlist) { setlist = current_variable_set_list; current_variable_set_list = setlist->next; } else { setlist = global_setlist.next; global_setlist.set = setlist->set; global_setlist.next = setlist->next; } free ((char *) setlist); }
This issue is related to PR22002. I have a patch. A slightly-more reduced testcase is: struct node { struct node *next; int value; }; struct node *current_node, global_list; void bar (void) { struct node *node, *next; node = current_node; next = node->next; if (node != &global_list) current_node = next; else { node = global_list.next; global_list.value = node->value; global_list.next = node->next; } foo (node); }
Subject: Bug 25514 Author: rsandifo Date: Thu Apr 27 16:41:51 2006 New Revision: 113312 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113312 Log: PR rtl-optimization/25514 * combine.c (replaced_rhs_insn): New variable. (combine_instructions): Set replaced_rhs_insn when trying to replace a SET_SRC with a REG_EQUAL note. (distribute_notes): Use replaced_rhs_insn when determining the live range of a REG_DEAD register. gcc/testsute * gcc.c-torture/compile/pr25514.c: New test. Modified: branches/csl/coldfire-4_1/ChangeLog.csl branches/csl/coldfire-4_1/gcc/combine.c
Subject: Bug 25514 Author: rsandifo Date: Thu Apr 27 16:43:10 2006 New Revision: 113313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113313 Log: PR rtl-optimization/25514 * combine.c (replaced_rhs_insn): New variable. (combine_instructions): Set replaced_rhs_insn when trying to replace a SET_SRC with a REG_EQUAL note. (distribute_notes): Use replaced_rhs_insn when determining the live range of a REG_DEAD register. gcc/testsute * gcc.c-torture/compile/pr25514.c: New test. Added: branches/csl/coldfire-4_1/gcc/testsuite/gcc.c-torture/compile/pr25514.c
Subject: Bug number PR25514 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00958.html
Subject: Bug 25514 Author: rsandifo Date: Mon May 22 15:58:03 2006 New Revision: 113983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113983 Log: PR rtl-optimization/25514 * combine.c (replaced_rhs_insn): New variable. (combine_instructions): Set replaced_rhs_insn when trying to replace a SET_SRC with a REG_EQUAL note. (distribute_notes): Use replaced_rhs_insn when determining the live range of a REG_DEAD register. gcc/testsute * gcc.c-torture/compile/pr25514.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr25514.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
Bisected down to r113983 (which was ment to fix this problem for m68k), I'm getting exactly this "internal consistency failure" when compiling parts of uClibc for vax-linux-uClibc. (That is, starting with r113981:-) From reading the mailing lists, this also happens for the hppa and ia64 ports.
Richard, I'm on another problem related to REG_NOTEs in the combiner (PR 29329) present on the 4.1 branch so I think it's time to make a definitive decision on this PR. I'd be in favor of backporting all your changes to the 4.1 branch but I'll let you and Roger decide. Thanks in advance.
Ack that, thanks Eric. Roger and I did discuss this a bit off-list, but I don't think we came to any conclusion. (Tardiness on my part being the dominant problem, sorry.) I think Roger is OK in principle with a backport, but the questions are (a) whether we should keep your patch on mainline too and, if not, (b) whether we should revert it on the branches too. Roger, let me know if I've misrepresented you there. Richard
> I think Roger is OK in principle with a backport, but the > questions are (a) whether we should keep your patch on > mainline too and, if not, (b) whether we should revert > it on the branches too. Roger, let me know if I've > misrepresented you there. I don't think my patch should be taken into account to make the decision. However, I can first revert it everywhere to make the backport easier.
Ping. :-)
Not sure what to think about the current state of affairs of the 4.1 branch and, consequently, about this PR. Anyone?
Eric asked me to weigh in here. My only concern about a backport is Comment #9, which suggests that the patch didn't work. I'm assuming that since we're all talking about backporting it, that comment was mistaken? If indeed there are no known problems, I think it's reasonable to put this on 4.1.
> Eric asked me to weigh in here. My only concern about a backport is Comment > #9, which suggests that the patch didn't work. I'm assuming that since we're > all talking about backporting it, that comment was mistaken? If indeed there > are no known problems, I think it's reasonable to put this on 4.1. Thanks Mark. It seems that a whole new class of internal consistency failures due to the mishandling of REG_NOTEs in the combiner appeared in 4.1.x (for example rtl-optimization/28243 and the blocked rtl-optimization/29329) and up. Richard's patch is the most generic fix available as of today, so backporting it or not to the 4.1.x branch has cascading effects on the other PRs. Maybe the problem reported in comment #9 is another variant. Richard, are you still ready to backport it? If so, I can revert my patch for rtl-optimization/28243 right now to make things easier.
Subject: Re: [4.0/4.1 regression] internal consistency failure ebotcazou at gcc dot gnu dot org wrote: > Thanks Mark. It seems that a whole new class of internal consistency failures > due to the mishandling of REG_NOTEs in the combiner appeared in 4.1.x (for > example rtl-optimization/28243 and the blocked rtl-optimization/29329) and up. > Richard's patch is the most generic fix available as of today, so backporting > it or not to the 4.1.x branch has cascading effects on the other PRs. Maybe > the problem reported in comment #9 is another variant. Do you mean positive cascading effects, in that bugs go away, or negative, in that new bugs show up? Do you think that backporting this patch is going to fix some bugs at the expense of breaking others? Thanks,
> Do you mean positive cascading effects, in that bugs go away, or > negative, in that new bugs show up? Positive cascading effects if the set of patch is backported to the branch. > Do you think that backporting this patch is going to fix some bugs at the > expense of breaking others? That will very likely fix again 28243 and help for 29329. I can make a quick pass on the various related PRs for mainline/4.2/4.1 over the week-end and post kind of an overview of the situation before you definitely decide.
Subject: Re: [4.0/4.1 regression] internal consistency failure ebotcazou at gcc dot gnu dot org wrote: > ------- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-01-05 18:33 ------- >> Do you mean positive cascading effects, in that bugs go away, or >> negative, in that new bugs show up? > > Positive cascading effects if the set of patch is backported to the branch. > >> Do you think that backporting this patch is going to fix some bugs at the >> expense of breaking others? > > That will very likely fix again 28243 and help for 29329. I can make a quick > pass on the various related PRs for mainline/4.2/4.1 over the week-end and > post kind of an overview of the situation before you definitely decide. I think I can do best by deferring to you, Roger, and Richard. It sounds like everyone's agreed that Richard's changes are the right thing, in principle. It also sounds like they have had little (no?) negative affect in practice. As long as we don't feel that we're unduly introducing risk (fixing one thing but breaking another), I'm all for putting the patches on the branch. I know Richard's busy (he's getting ready to submit a big batch of changes), so if you feel like trying the backport you might want to give it a go. Otherwise, I'm sure Richard will get to it in the relatively near future.
> I know Richard's busy (he's getting ready to submit a big batch of > changes), so if you feel like trying the backport you might want to give > it a go. Otherwise, I'm sure Richard will get to it in the relatively > near future. OK, I'm going to give it a whirl.
Subject: Re: [4.0/4.1 regression] internal consistency failure "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: >> Eric asked me to weigh in here. My only concern about a backport is Comment >> #9, which suggests that the patch didn't work. I'm assuming that since we're >> all talking about backporting it, that comment was mistaken? If indeed there >> are no known problems, I think it's reasonable to put this on 4.1. > > Thanks Mark. It seems that a whole new class of internal consistency failures > due to the mishandling of REG_NOTEs in the combiner appeared in 4.1.x (for > example rtl-optimization/28243 and the blocked rtl-optimization/29329) and up. > Richard's patch is the most generic fix available as of today, so backporting > it or not to the 4.1.x branch has cascading effects on the other PRs. Maybe > the problem reported in comment #9 is another variant. > > Richard, are you still ready to backport it? If so, I can revert my patch for > rtl-optimization/28243 right now to make things easier. Yup, I'm still ready to backport it if the consensus is that the patch is OK for 4.1. I see from later comments that you might be backporting it yourself, but the offer still stands if you haven't started yet. Richard
> Yup, I'm still ready to backport it if the consensus is that > the patch is OK for 4.1. I see from later comments that you > might be backporting it yourself, but the offer still stands > if you haven't started yet. I only resynced my 4.1 branch (it changed a lot recently) and got a baseline, so I've not really started. OK, please do it and I'll only do the reversion of my patch on all branches. Thanks again.
Subject: Bug 25514 Author: rsandifo Date: Sat Jan 6 14:26:58 2007 New Revision: 120526 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120526 Log: gcc/ Backport: 2006-05-23 Richard Sandiford <richard@codesourcery.com> PR rtl-optimization/27736 * combine.c (replaced_rhs_value): New variable. (combine_instructions): Set it. (distribute_notes): When distributing a note in replaced_rhs_insn, check whether the value was used in replaced_rhs_value. 2006-05-22 Richard Sandiford <richard@codesourcery.com> PR rtl-optimization/25514 * combine.c (replaced_rhs_insn): New variable. (combine_instructions): Set replaced_rhs_insn when trying to replace a SET_SRC with a REG_EQUAL note. (distribute_notes): Use replaced_rhs_insn when determining the live range of a REG_DEAD register. gcc/testsuite/ 2006-05-22 Richard Sandiford <richard@codesourcery.com> PR rtl-optimization/25514 * gcc.c-torture/compile/pr25514.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr25514.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/combine.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
Fixed in upcoming 4.1.2, the 4.0 branch is now closed.