Bad code from egcs-1.1b

[Jeffrey A Law]

  In message < u9emrvbzxh.fsf@yorick.cygnus.com >you write:
  > Oops, communications failure; I'm talking about moving the notes in
  > expand_end_loop.  We currently don't because we're afraid of breaking the
  > order, but in most cases moving them won't cause any problems.
Whoops.  But I don't think we've had a major communication failure.  I think
most of the same comments apply.

  >  >> Another possibility would be to associate the fixup with something
  >  >> other than a block; perhaps a code_label?
  > 
  >  > This is interesting.  Assuming I understand the problem, you actually
  >  > don't want to associate with the note or any existing label, but instead
  >  > the edge as you leave an inner scope to an outer scope.
  > 
  > Yes.  Specifically, we want to associate with the jump that is emitted just
  > after we call expand_fixup.
Is it important that the cleanup code be bounded by these notes?  
Associating with the jump brings some bookkeeping problems -- think about code
which loops and does something like emit_insns_after (insns, f->before_jump).
Then again, maybe order doesn't matter for the cleanups?

We could emit a nop-like insn before the jump, then set f->before_jump to the
nop insn, which avoids having to rewrite any of the cleanup insertion code
I believe.  We could even emit a NOTE_INSN_DELETED or something else like
that if we wanted to avoid creating a nop reg->reg copy.

  > Yes and no.  EH makes this more complicated; semantically, each cleanup is
  > in the next outer EH region.  We currently handle this by wrapping the
  > fixup cleanups in their own regions which just rethrow to the region
  > outside the one they are the cleanup for.  If we have popped the inner
  > scope, their regions will not be on ehstack anymore, so we won't be able to
  > find the right place to rethrow to.
I was fine up until this point :-)  I belive I'm thinking at much lower level
than I think you are.  We don't actually have to pop the region.


  > Couldn't we just use another kind of note?  Or, for that matter, keep a
  > pointer to the jump?
Using another note means making sure everything else knows how to deal with
that new note, unless you magically promote it to a BLOCK_{BEG,END} pair
after you insert the cleanup code (jump, final, integrate come immediately to
mind as needing fixing if we add a new note for this stuff).

I'm thinking the easiest solution is either a nop copy or NOTE_INSN_DELETED
right after the BLOCK_BEGIN note and setting f->before_jump to point to the
nop copy/NOTE_INSN_DELETED.

This won't work we we actually need the BLOCK_BEGIN/BLOCK_END to bound the
cleanup code for some reason.

jeff