On Tue, Jul 14, 2009 at 1:17 AM, Kaz Kojima<kkoj...@rr.iij4u.or.jp> wrote:
> [I'd like to add kenny to the CC list.]
I doubt he can help you with this one... When your problem concerns
reorg, you should talk to people like Eric Botcazou or Richard
Sandiford or HP Nillson. I've added Eric to the CC, to make this a
happier crowd. :-)
> Steven Bosscher <stevenb....@gmail.com> wrote:
>> So when the CFG is still valid, r15 is live-out in basic block 2 and
>> live-in in basic block 3 (which contains insns 32, whatever that means
>> for an invalid CFG). For which bb does mark_target_live_regs call
>> df_get_live_in?
>
> gdb says
>
> 920 b = find_basic_block (target, MAX_DELAY_SLOT_LIVE_SEARCH);
>
> returns 2.
OK, so isn't the bug obvious then? You said: "mark_target_live_regs
uses df_get_live_in to get live regs for the basic block including the
opposite_thread insn which is insn 32.". And you had insn 32 in basic
block 3. So find_basic_block returns the wrong basic block.
reorg.c:find_basic_block uses BLOCK_FOR_INSN, which is not valid after
freeing the CFG. The bug you see occurs now because your backport of
the other DF/reorg fixes (your patch for PR40105) also introduces a
call to free_bb_for_insn which clears BLOCK_FOR_INSN. And since
find_basic_block skips over NOTE_INSN_BASIC_BLOCK notes (it uses
{prev,next}_nonnote_insn) and basic block 3 doesn't start with a
label, find_basic_block never sees the start of basic block 3.
I am not even sure why it finds basic block 2. Is there a label in
basic block 2 that you were not showing in the original post?
Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes?
Ciao!
Steven
