Consider this C file: extern void e (int) __attribute__ ((noreturn)); void f (char *p, int a, int b, int c) { int i, j; j = 0; for (i = 0; i < 10; ++i) { switch (a) { case 0: p[i] = 0; break; case 1: if (c == 1) { if (j < 0 | b <= j) e (0); p[j] = 0; } else { if (j < 0 | b <= j) e (0); p[j] = 0; } j++; } } } When I use a compiler built for the m68k-rtems4.11 target, the compiler crashes when I compile this file with the options -O2 -mcpu=5206 -fwrapv. /home/iant/gcc/m68k-rtems-objdir/./gcc/xgcc -B/home/iant/gcc/m68k-rtems-objdir/./gcc/ -O2 -mcpu=5206 -S -fwrapv foo.c foo.c: In function 'f': foo.c:31:1: internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:845 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. I will describe what I think is happening, although I have not proved it. The crash occurs because try_head_merge_bb in cfgcleanup.c moves a CC0-setter away from the CC0-user. It finds a common sequence in two basic blocks--I believe it is the finding of this common sequence which makes this test requires the -mcpu=5206 -fwrapv options. Finding the common sequence respects CC0 requirements. However, it then calls can_move_insns_across. That returns false, because there is a register conflict--d0 is used by the predecessor block and the common sequence. However, can_move_insns_across also returns move_upto, indicating which insns may be moved. can_move_insns_across does not check for cc0 when setting move_upto, and try_head_merge_bb doesn't check for it when using move_upto. The effect is that the cc0 setter is moved, leaving the cc0 user behind. This leads to the later crash.
Just a note that it happens with revision 169771. This is a regression as it works with 4.5.2, 4.4.5, 4.3.2
Related to PR 47459.
It's similar to PR 46878 in that this is also CC0 related, but it is different code that is splitting up the CC0 setter and the CC0 user. My sources do include the patch for PR 46878.
I can reproduce the ICE with a cross to m68k-elf. It's caused by r167779: Author: bernds Date: Tue Dec 14 00:23:40 2010 New Revision: 167779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167779 Log: gcc/ PR rtl-optimization/44374 Reapply patch with fixes. ...
I confirm I have also hit this bug on GCC 4.6.0 release for the unofficial m68k-atari-mint target with only "-mcpu=5475 -O2" on a rather big and complicated file.
Created attachment 23850 [details] Testcase Here is my simplified testcase. It looks weird, but I didn't manage to simplify more. It fails with ICE when compiled using: gcc -c bug.c -mcpu=5475 -O2
Created attachment 23890 [details] Potential fix. Please test this patch.
Excellent! Your patch fixes both testcases here.
Any chance you can run the testsuite before/after the patch? m68k is problematic due to lack of a simulator.
(In reply to comment #9) > Any chance you can run the testsuite before/after the patch? m68k is > problematic due to lack of a simulator. I can test with RTEMS on Qemu targeting an mc5282 Coldfire. I just started a build and test sweep without the patch. Give me a bit to post test results without and with the patch. FWIW gcc 4.6.0 does fail with the test case and 5282 so this will be a good sweep. $ m68k-rtems4.11-gcc -O2 -mcpu=5282 -fwrapv -c j2.c j2.c: In function 'bug': j2.c:19:1: internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:845 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
In both cases, I built gcc + newlib multilib + rtems multilib to ensure the entire software base was built with and without the patch. $ m68k-rtems4.11-gcc --version m68k-rtems4.11-gcc (GCC) 4.6.1 20110329 (prerelease) Without patch.. results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000516.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00525.html === gcc Summary === # of expected passes 67228 # of unexpected failures 386 # of expected failures 121 # of unresolved testcases 77 # of unsupported tests 1095 === g++ Summary === # of expected passes 24705 # of unexpected failures 720 # of expected failures 162 # of unsupported tests 449 With the patch ... results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000517.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00533.html === gcc Summary === # of expected passes 67231 # of unexpected failures 383 # of expected failures 121 # of unresolved testcases 77 # of unsupported tests 1095 === g++ Summary === # of expected passes 24705 # of unexpected failures 720 # of expected failures 162 # of unsupported tests 449 It looks like it didn't make anything worse and fixed 3 C tests. :-D I think this should be committed to the 4.6 branch and head. If you like, we can repeat the experiment on the 4.5 branch if that is desired. FWIW I would be happy to help run down some of the failure cases if someone is interested in trying to fix them. :-D
Created attachment 23909 [details] Better fix Sorry to do this to you, but can you test this one? I looked at the code again a bit more closely and I believe the previous patch was incorrect :-(
Not a problem to redo.. just CPU time and if you don't use it, you lose it. :-D I am repeating some information so it is all in one post. In both cases, I built gcc + newlib multilib + rtems multilib to ensure the entire software base was built with and without the patch. $ m68k-rtems4.11-gcc --version m68k-rtems4.11-gcc (GCC) 4.6.1 20110329 (prerelease) Without patch.. results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000516.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00525.html === gcc Summary === # of expected passes 67228 # of unexpected failures 386 # of expected failures 121 # of unresolved testcases 77 # of unsupported tests 1095 === g++ Summary === # of expected passes 24705 # of unexpected failures 720 # of expected failures 162 # of unsupported tests 449 With the patch ... results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000518.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00577.html === gcc Summary === # of expected passes 67230 # of unexpected failures 384 # of expected failures 121 # of unresolved testcases 77 # of unsupported tests 1095 === g++ Summary === # of expected passes 24705 # of unexpected failures 720 # of expected failures 162 # of unsupported tests 449 Only an increase of two passes. I don't know what was the 3rd test that passed with the previous patch and not with this one.
From the test results you posted, it appears to have been +WARNING: program timed out. +FAIL: gcc.dg/torture/fp-int-convert-double.c -O2 -flto execution test Probably unrelated.
(In reply to comment #14) > From the test results you posted, it appears to have been > > +WARNING: program timed out. > +FAIL: gcc.dg/torture/fp-int-convert-double.c -O2 -flto execution test > > Probably unrelated. When I compiled it by hand and ran it, it passed. I think that makes the test results the same. Strangely, none of the gcc.dg/torture tests that failed appear to have left executables. :(
Author: bernds Date: Wed May 4 20:24:15 2011 New Revision: 173393 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173393 Log: PR rtl-optimization/47612 * df-problems.c (can_move_insns_across): Don't pick a cc0 setter as the last insn of the sequence to be moved. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c
For me the bug seems to be fixed.
I have applied your patch to GCC 4.6.1 and it worked fine on all the software I'm used to compile. You should apply it to the 4.6 branch.
Time to close this?
(In reply to comment #19) > Time to close this? Not until the patch gets applied to gcc-4.6 branch.
Please properly mark regressions and backport the fix ASAP if appropriate.
The fix applies as-is to gcc-4.6 with only a fuzz in line offset.
GCC 4.6.3 is being released.
The 4.6 branch has been closed, fixed in GCC 4.7.0.