http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-12 08:54:29 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172430 but more probably this is just a dup of PR48813, which was for this testcase latent before. Honza, any chance you could look at that and PR48813? The ICE is in the exact same spot, base_loop is non-NULL, but base_loop->header is NULL, as the loop has been marked for removal in delete_basic_block called from remove_bbs/remove_path during the peeling. The same remove_path then calls fix_loop_placements which calls fix_bb_placements which ICEs. That delete_basic_block is apparently called on the loop->latch bb, which queues the loop for removal anyway, but loop->header hasn't been removed and its bb->loop_father still points to the loop that has now header and latch fields NULL.
