This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ongoing problems with resource.c changes
- To: law at cygnus dot com
- Subject: Re: Ongoing problems with resource.c changes
- From: Geoff Keating <geoffk at ozemail dot com dot au>
- Date: 02 Nov 1999 14:39:52 +1100
- CC: gcc at gcc dot gnu dot org, rth at cygnus dot com
- References: <6422.941511457@upchuck>
Jeffrey A Law <law@cygnus.com> 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 <http://egcs.cygnus.com/ml/gcc-patches/1999-10/msg00692.html>.
--
Geoffrey Keating <geoffk@cygnus.com>