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: Crash in garbage collector


"Jon Beniston" <jbeniston@compxs.com> writes:
> I have been working on a port of GCC to a new architecture, which for
> the most part is compiling reasonably well. However, for a few files, I
> am seeing crashes in the garbage collector. The first time I had this
> problem, it disappeared when I changed:
> 
> label = gen_rtx (LABEL_REF, VOIDmode, operands[0]);
> 
> To 
> 
> label = gen_rtx_LABEL_REF (VOIDmode, operands[0]);
> 
> in one of my machine specific source files. Can anyone explain how this
> might have effected things?
> [...]
> Incidentally, this happens on both Linux and Cygwin. My port is based on
> the gcc-3.3.2 release.

In the 3.3 series, gen_rtx() left '0'-type fields uninitialised.
Since the definition of LABEL_REF is:

    /* Reference to an assembler label in the code for this function.
       The operand is a CODE_LABEL found in the insn chain.
       The unprinted fields 1 and 2 are used in flow.c for the
       LABEL_NEXTREF and CONTAINING_INSN.  */
    DEF_RTL_EXPR(LABEL_REF, "label_ref", "u00", 'o')

this means that gen_rtx (LABEL_REF, ...) would only initialise the
first operand, not the other two.  Unfortunately, I think all three
operands are garbage collected, see gengtype.c:adjust_field_rtx_def().
So you'd end up collecting random addresses.

gen_rtx_LABEL_REF() sets the other two operands to null, so there's no
problem if you use that.

FWIW, the 3.4 version of gen_rtx() will initialise '0' fields to null.

Richard


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