Treat SEQUENCE specially in mark_jump_label.
Sun Mar 25 22:17:00 GMT 2007
On Wednesday 21 March 2007 00:47, Bernd Schmidt wrote:
> I've committed the following patch, which fixes a segfault in the
> Blackfin compiler while building libgcc.
> Recently, cfg_layout_finalize has started to call rebuild_jump_labels
> which in turn calls mark_jump_label. The Blackfin reorg pass uses
> cfg_layout, and mark_jump_label doesn't cope with the SEQUENCE insns we
> Bootstrapped and regression tested on i686-linux. I get one additional
> +FAIL: gcc.dg/noncompile/920923-1.c -O3 -g (test for excess errors)
> which, from looking at the log, seems to be a dejagnu problem (the
> compiler output appears truncated).
This looks like SEQUENCE abuse to me. SEQUENCE shouldn't be used
anymore, and effort was made to remove it from the compiler entirely,
see e.g. http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00535.html.
You even say in bfin.c that you have to cheat the compiler to make
your SEQUENCE hack work at all:
/* This is a cheat to avoid emit_insn's special handling of SEQUENCEs.
Generating a PARALLEL first and changing its code later is the
easiest way to emit a SEQUENCE insn. */
bundle = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (3, slot, slot, slot));
emit_insn_before (bundle, slot);
PUT_CODE (bundle, SEQUENCE);
I see no reason to litter the compiler with code to handle SEQUENCE
again, unless we allow it as a proper citizen again everywhere else,
At the very least you should add a comment in (mark_jump_labels why
this is needed. Right now it is completely unclear why this is needed
in mark_jump_labels, but not also in init_label_info. Actually I think
that if this the way we wish to go, then you should add code to handle
SEQUENCE in init_label_info too.
Anyway, I don't like the patch. Is there really no other way for the
blackfin port to just avoid SEQUENCE completely?
More information about the Gcc-patches