Re: Lazy allocation of DECL_ASSEMBLER_NAME

[Geoff Keating <geoffk at desire dot geoffk dot org>]

> From: Zack Weinberg <zack@codesourcery.com>
> Date: Mon, 01 Mar 2004 11:57:56 -0800

> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > Likewise, I believe with Zack's c-decl changes, I believe that it
> > always returns the new DECL,
> 
> I can't speak to anything else here, but this is not true; I
> considered that approach and rejected it.  The thrust of the
> (currently incomplete) work is now to always use the oldest decl,
> adding information from later ones as necessary.  Cases where that
> does not happen are bugs - the bugs I've been trying to fix; the whole
> problem is that the middle end is not prepared to cope with multiple
> DECLs for the same object.

That does sound like a good plan.  The difficulty will be in ensuring
that the newer decl is not used before duplicate_decls is called on
the pair of decls; in particular, this will require some changes to
IMA, merge_translation_unit_decls will need to go away because
duplicate_decls will have to be called when the decl is seen rather
than later on.  I've wanted to do this ever since we removed the GCC
extension that made it necessary to do this as a final pass, but don't
have time right now.

Is this going to be necessary for 3.4?  It sounds like a lot of work
very late in the release cycle.  It may be better to have the
middle-end compare DECL_ASSEMBLER_NAME for 3.4 and make these changes
in 3.5.

(I've added Dale since he was struggling with a related problem in the
tree-ssa branch, and neither he nor I knew about this new requirement
for 'one DECL' in the backend.)

-- 
- Geoffrey Keating <geoffk@geoffk.org>