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.
