Created attachment 21948 [details] preprocessed C++ source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: i686-pc-linux-gnu Configured with: ../configure --disable-bootstrap --enable-languages=c++ Thread model: posix gcc version 4.6.0 20101003 (experimental) [trunk revision 164915] (GCC) $ ./xgcc -B. -O2 ~/ice.ii /home/ryan/ice.ii: In static member function ‘static Status Mpeg2FrameConstructor::ParsePictureHeader(Ipp8u*, Ipp32s, Mpeg2TrackInfo*)’: /home/ryan/ice.ii:36:21: error: BB 2 can not throw but has an EH edge /home/ryan/ice.ii:36:21: error: BB 3 can not throw but has an EH edge /home/ryan/ice.ii:36:21: error: BB 4 can not throw but has an EH edge /home/ryan/ice.ii:36:21: error: BB 5 can not throw but has an EH edge /home/ryan/ice.ii:36:21: error: BB 6 can not throw but has an EH edge /home/ryan/ice.ii:36:21: error: BB 7 can not throw but has an EH edge /home/ryan/ice.ii:36:21: error: BB 11 can not throw but has an EH edge /home/ryan/ice.ii:36:21: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. ryan@zoidberg:~/gnu/gcc/trunk/tmp1/gcc$
It looks like IPA-CP does not properly adjust callers EH info. Or eh-dispatch is bogus (which is where the ICE happens).
Something in the ipa-cp/ipa-inline transform machinery leaves stray eh cfg edges. Calling gimple_purge_dead_eh_edges() unconditionally in ipa-transform makes the ICE go away. For example the following patch does: Index: gcc/tree-optimize.c =================================================================== --- gcc/tree-optimize.c (revision 165301) +++ gcc/tree-optimize.c (working copy) @@ -283,8 +283,8 @@ execute_fixup_cfg (void) todo |= TODO_cleanup_cfg; } - if (maybe_clean_eh_stmt (stmt) - && gimple_purge_dead_eh_edges (bb)) + maybe_clean_eh_stmt (stmt); + if (gimple_purge_dead_eh_edges (bb)) todo |= TODO_cleanup_cfg; } Nevertheless, I'd like to find out where we either call maybe_clean_eh_stmt or do something equivalent without removing the cfg edges before deciding where we should do it.
I am out of the office until October 28th,2010. I will have periodic access to email in the meantime. For urgent issues please contact Fred Plante <fplante@qnx.com>
It is triggered by revision 164561: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00858.html
That makes sense - either this fn needs to clean dead EH edges (gsi_replace cleans EH regions only ...) or the callers need to. Mine.
Author: rguenth Date: Wed Oct 13 10:06:28 2010 New Revision: 165416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165416 Log: 2010-10-13 Richard Guenther <rguenther@suse.de> PR middle-end/45874 * cgraphunit.c (cgraph_redirect_edge_call_stmt_to_callee): Fixup the CFG when EH was fixed up. * g++.dg/torture/pr45874.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr45874.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
Fixed.