This is the mail archive of the 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]

Re: Ongoing problems with resource.c changes

Jeffrey A Law <> writes:

> We're still having problems with the BLOCK_NUM stuff.
> The latest problem appears when we call mark_target_live_regs with an
> ADDR_VEC insn.

> Apparently the ADDR_VEC insn isn't actually within the bb->head/end
> bounds for its basic block and thus compute_bb_for_insn never
> initializes an entry in basic_block_for_insn for the ADDR_VEC.

> Thus when we call BLOCK_NUM (addr_vec insn) we blow up dereferencing a null
> pointer.

Yes.  I sent in a related patch for flow for a similar problem just
recently; what was happening is that the switch statement was being
partially folded out (so the jump didn't USE the ADDR_VEC any more),
but there were still references to the ADDR_VEC's label and so it
didn't go away.

The best proposed long-term fix was to stop using ADDR_VECs, and treat
switch statement tables like other constants (create a new
CONST_ADDR_VEC rtl type like CONST_DOUBLE).  The problems are all
related to trying to treat data (the ADDR_VEC) like code.

See <>.

Geoffrey Keating <>

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