regehr@john-home:~/volatile/tmp147$ current-gcc -O2 small.c -Wall -c small.c: In function ‘uint8func’: small.c:9: internal compiler error: in purge_dead_edges, at cfgrtl.c:2274 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. regehr@john-home:~/volatile/tmp147$ cat small.c int func(int); volatile unsigned char g_100; void uint8func (int p_34) { char l_125 = 0xE1; func ((func ((p_34 & g_100) <= l_125), 1)); } regehr@john-home:~/volatile/tmp147$ current-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r146634-install --program-prefix=r146634- --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20090423 (experimental) (GCC)
Confirmed.
Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274 The problem here is that combine constructs (set (pc) (pc)) as noo-op move expecting it to be removed immediately. It is however misinterpreted as jump that is giong to be removed at the end of BB and update_cfg_for_uncondjump add FALLTHRU flag on the edge that fails in verification. Interestingly enough modifying update_cfg_for_uncondjump to ignore insns that are not last in BB seem to cause miscompilations in testsuite.... I am looking into the cgraph failures now, but this should be easy to fix. Honza
Honza, this worked for me: Index: combine.c =================================================================== --- combine.c (revision 149135) +++ combine.c (working copy) @@ -2173,12 +2173,13 @@ update_cfg_for_uncondjump (rtx insn) { basic_block bb = BLOCK_FOR_INSN (insn); + bool at_end = (BB_END (bb) == insn); - if (BB_END (bb) == insn) + if (at_end) purge_dead_edges (bb); delete_insn (insn); - if (EDGE_COUNT (bb->succs) == 1) + if (at_end && EDGE_COUNT (bb->succs) == 1) single_succ_edge (bb)->flags |= EDGE_FALLTHRU; } Would you mind seeing if your patch was the same?
Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274 > Would you mind seeing if your patch was the same? I wanted to prevent the (set pc pc) trick, but this seems like easier fix for the problem :) Honza
See also bug 40716.
*** Bug 40716 has been marked as a duplicate of this bug. ***
Also happens on i586-pc-mingw32 and with -m64 on i386-apple-darwin9. This P1 regression is more than 4 months old, and has a proposed patch; could someone post the patch for review?
It is caused by revision 145283: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00790.html
Fixed on trunk at revision 151895.
*** Bug 40364 has been marked as a duplicate of this bug. ***