Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names

[Michael Matz <matz at suse dot de>]

Hi Bill,

On Fri, 1 Aug 2008, Diego Novillo wrote:

> > Finding that DECL_CONTEXT might include portions of what looked like
> > template definitions, and surmising that  lexical nesting was a
> > language artifact that should no longer be of significance beyond the
> > front-end, I attempted to clear DECL_CONTEXT in free_lang_specifics.
> > This resulted in an assertion failure in
> > cp/mangle.c:write_unscoped_name.  It appears that the name mangling
> > code, as one would expect, is very interested in such nesting, and
> > examines DECL_CONTEXT in multiple locations.  None of this would be of
> > any consequence if the name mangling were complete upon entry to the
> > middle-end, but it can in fact be invoked via a langhook from
> > DECL_ASSEMBLER_NAME.  Setting the assembler name is performed lazily
> > in the back-end, requiring nesting relationships reflected in
> > DECL_CONTEXT to be preserved to this point.
> >
> > My assertion is that the langhook must go, and that mangled names
> > should be generated before invoking the middle-end.  Given the baroque
> > treatment of the assembler name, however, I don't think it will be
> > sufficient simply to make a pass over the declarations in
> > free_lang_specifics setting the assembler name.
> >
> > Any advice from someone who deeply understands this stuff?

See also my patch from 
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html that had to deal 
with the same problem.  It indeed simply sets the asm name from 
free_lang_specifics (see set_asm_name() in there).  One issue is to watch 
out for string memory, one potentially generates names for decls that 
later are thrown away.  I found this to be only a minor issue with 
tramp3d, though.


Ciao,
Michael.