http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #6)
> > I think the problem is that ifcvt relies on consistent counting of insns,
> > but the various functions count different things.
>
> What kind of insns is responsible for the discrepancy that leads to the ICE?
On the given testcase the JUMP_INSN at the end of bb is returnjump_p (without
additional side effects), so it isn't counted and thus that problem isn't
present. But the problem on the testcase is insn with USE pattern right before
the jump, count_bb_insns counts it as active insn, flow_find_cross_jump
doesn't, and we subtract from the former the latter to see how many insns we
should allow at most for flow_find_head_matching_sequence, and because of the
discrepancy it is one bigger than it should and we end up with
then_last_head being after then_end, which violates the assumptions the code
makes.
> > 3) perhaps not count USE/CLOBBER insns in flow_find_head_matching_sequence
> > if
> > stop_after is non-zero?
>
> I'd first make the functions behave the same wrt USE and CLOBBER insns.
Perhaps we can ignore those always in flow_find_head_matching_sequence?
> > 4) perhaps add also skip_use argument to first_active_insn and if TRUE,
> > ignore USE insns and for both {first,last}_active_insn if skip_use is TRUE,
> > also ignore CLOBBER insns
> >
> > 5) in find_active_insn_{before,after} ignore USE/CLOBBER insns
> > and document this properly?
>
> I'm less sure about these ones: does their behavior need to be in keeping
> with the insns counting?
Perhaps, though I'd say it might be a ticking bomb.
