On Tue, Apr 12, 2011 at 10:29:57AM +0200, Eric Botcazou wrote:
> > 2011-04-12 Jakub Jelinek
> >
> > PR rtl-optimization/48549
> > * combine.c (propagate_for_debug): Also stop after BB_END of
> > this_basic_block. Process LAST and just stop processing after it.
> > (combine_instr
> That is because propagate_for_debug stops at the insn before last, doesn't
> process last any longer. So, if there is a DEBUG_INSN right before the
> jump being deleted, and it has been propagated into, after the jump is
> deleted and retry is done at i2 earlier, following propagate_for_debug
>
On Tue, Apr 12, 2011 at 09:18:01AM +0200, Eric Botcazou wrote:
> > With the second patch, bootstrap succeeded even with gcc_assert (at_end);
> > in update_cfg_for_uncondjump, so either it is always at the end, or at
> > least very often, thus perhaps with the second patch being applied
> > in combi
> The propagate_for_debug change alone could fix it, we should never
> fall through into next basic block. We are unforuntately not deleting
> just jumps (which ought to appear at the end of bbs), but also
> any other noop moves, which I think is unintentional, we have
> delete_noop_moves that sho
Hi!
On the testcase below we ICE since my PR48343 patch.
The problem is that update_cfg_for_uncondjump delete_insns the noop move,
if the insn to be deleted is last_combined_insn (which can be both
if it is i3 or when retrying and undobuf.other_insn happens to be
last_combined_insn), next propagat
