Re: Ongoing problems with resource.c changes

[Jeffrey A Law <law at cygnus dot com>]

  In message <19991101194214.A31754@cygnus.com>you write:
  > On Mon, Nov 01, 1999 at 07:57:37PM -0700, Jeffrey A Law wrote:
  > > Apparently the ADDR_VEC insn isn't actually within the bb->head/end bound
  > s
  > > for its basic block and thus compute_bb_for_insn never initializes an ent
  > ry
  > > in basic_block_for_insn for the ADDR_VEC.
  > 
  > Give this a shot -- I've just fired off a Sparc bootstrap.  I'll
  > find out if it worked after dinner.
  > 
  > This is Jan's patch with minor modifications to cope with the above.
Blows up compiling cccp, cexp, etc.

The problem is reorg calls redirect_jump.  If in the process of redirecting
a jump we may delete code.  Both actions (redirecting the jump & deleting code)
can make the cfg data inaccurate.

If we happen to do anything like try to walk the insns in a basic block we
lose as the insn pointed to by bb->end may have been unlinked from the insn
chain.

Having jump.c work on the cfg and incrementally update it would probably solve
this problem.  But I don't think we want to tie that effort into just getting
the compiler to work again.

The particular case I was looking at can be solved by calling
init_resource_info earlier in reorg.c.  But I don't know if that's really
sufficient to solve the problems we're having.

jeff