Re: 980729-1.c:14: Virtual array basic_block_for_insn[82]: element 86 out of bounds in merge_blocks_nomove, at flow.c:2887

[Jan Hubicka <jh at suse dot cz>]

> 
> I synced up as of early afternoon today 7/29/01, and see a large
> number (70 maybe?) testsuite failures due to the varray overflowing its bounds.
> It seems improbable that my port is the only one that would hit these
> things.
> 
> Jan, have you been just bootstrapping the compiler, or have you been
> running the c-torture testsuite also?
I did both (all testsuites, not only c-torture).
What architecture do you use?
I've just tested the testsuite you are mentioning on i386 and get no failure.
> 
> It appears that in this case, we have grown the varray to 82 elements
> before reload.  Reload allocates a bunch of new INSNS (not too
> surprising) and then when we call cleanup_cfg(), it tries to find the
> basic block associated with INSN 86 when surprise!!  We haven't grown
> the basic_block_for_insn array and won't until after cleanup_cfg ()
> finishes....
This happends, when some pass emits instructions, but do not update bb_for_insn.
Basic block merging then errs.
> 
> Here's the code in toplev
> 
>   cleanup_cfg (0);
> 
>   /* On some machines, the prologue and epilogue code, or parts thereof,
>      can be represented as RTL.  Doing so lets us schedule insns between
>      it and the rest of the code and also allows delayed branch
>      scheduling to operate in the epilogue.  */
>   thread_prologue_and_epilogue_insns (insns);
> 
>   compute_bb_for_insn (get_max_uid ());
Toes help you to move the compute_bb_for_insn before cleanup_cfg?

commit_edge_insertions now used by compute_bb stuff should take care
to re-update data.

block_for_insn array issues are getting messy and I would like to kill
it/replace by something more robust on the branch.

Honza