http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662
--- Comment #4 from Andrey Belevantsev <abel at gcc dot gnu.org> --- Created attachment 30650 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30650&action=edit proposed patch When moving up an instruction, we can make empty basic blocks or create other possibilities for control flow simplification, thus we do it along the way. This means that while we are in the iterator over successor blocks, those blocks could change, and we need to rescan successors to make sure we visit all of them. We do that with checking whether the number of successor blocks of the visiting block changed or the visiting block index itself changed, and we get hold of the visiting block via its last insn. Now, the problem is that this last insn itself can be removed during simplification. I have convinced myself that only case when this might happen is when the insn is an unconditional jump (the conditional jump might be changed to unconditional but not removed altogether). In this case we had a single successor and we have already visited it, so we just break from the successor iterator instead of attempting to rescan. I will test the attached patch and submit if succesful.
