Re: Abort in redirect_edge_and_branch on vax at line 866

[law at redhat dot com]

  > Really?  I'd have thought that only merging basic blocks would
  > cause problems.  We're not doing that.
Nope.  My recollection was that removing the jump itself along with
removing any code which becomes unreachable as a side effect of removing
the jump as causing implementation problems.

I see that delete_insn no longer has the side effect of deleting code
which becomes unreachable due to deleting the original insn.  That makes
me feel a lot better!  Boy I need to keep up with development better.

Probably the only problem that I can envision arising now would be 
looking at BLOCK_{HEAD,END} and getting back an insn that has been deleted
and removed from the chain of insns.    That would make a loop like this
do the wrong thing:

      for (insn = BLOCK_HEAD (bb);
           insn != NULL && insn != NEXT_INSN (BLOCK_END (bb));
           insn = NEXT_INSN (insn))


gcse::cprop has such a loop and I believe such loops exist in store_motion.


compute_store_table does something similar:

  /* Find all the stores we care about.  */
  for (bb = 0; bb < n_basic_blocks; bb++)
    {
      regvec = & (reg_set_in_block[bb]);
      for (insn = BLOCK_END (bb);
           insn && insn != PREV_INSN (BLOCK_HEAD (bb));s
           insn = PREV_INSN (insn))

cprop may have deleted BLOCK_END(bb), which will cause this loop to not
do what we expect it to do.

Maybe it doesn't actually matter, but I'd feel a lot better if we kept the
BLOCK_HEAD and BLOCK_END valid when we delete insns in cprop_jump
and cprop_cc0_jump.

jeff