http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > Now insn 24 is an unconditional trap and is considered a control flow > altering insn (see Eric's change for PR29841). Since we have a control flow > altering insn in the middle of a block, we trip the checking failure. > > This seems like a pretty fundamental problem. I can't think of any other > case where we allow optimizations to turn an insn which does not alter flow > control into a flow control altering insn (obviously we allow the opposite > and it's good). Yet the comment I added should have made it clear that I didn't invent this, look at the CALL_INSN case just above. For example, turning a conditional no-return call into an unconditional one will have the same effect. > This means that every pass which might potentially turn a conditional trap > into an unconditional trap would have to run DCE afterwards or otherwise > cleanup the code after the trap to avoid this problem. Not good. > > Or we would have to force each optimizer which might potentially turn a > conditional trap into an unconditional trap run find_many_sub_basic_blocks. Yes, that's a generic issue with passes making things unconditional, the CFG must be updated.
