This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A question about df_get_live_in


Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> 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.

Ugh.

> 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?

There are no labels in basic block2.  gdb says it hits the start
of the function and returns with

150       else if (insn == 0)
151         return ENTRY_BLOCK_PTR->next_bb->index;

> Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes?

The same question arises to me.

Regards,
	kaz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]