Lazy allocation of DECL_ASSEMBLER_NAME

[Geoff Keating]

> From: Zack Weinberg <zack@codesourcery.com>
> Date: Mon, 01 Mar 2004 13:15:52 -0800

> Mark Mitchell <mark@codesourcery.com> writes:
> > Geoff Keating wrote:
> >>>From: Zack Weinberg <zack@codesourcery.com>
> >>>The thrust of the (currently incomplete) work is now to always use
> >>>the oldest decl, adding information from later ones as necessary.
> >>
> >>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.
> 
> Yes.  I have partial code implementing this.  The fiddliest part is
> the nontransitive type comparison problem that Dale is encountering.
> I personally think that the front end should go to whatever lengths
> are necessary to present just one type to the language-independent
> compiler, even across multiple translation units, even in the presence
> of a nontransitive type system.  I think this is easier than it might
> sound - the trick I have in mind is permuting TYPE_MAIN_VARIANT so
> that it's always the appropriate choice for *this* translation unit.

It might be difficult to determine which translation unit is "this
unit" at any given point; you might have code that does:


struct foo;
extern struct foo * make_a_foo (void);
extern void use_a_foo (struct foo *);

extern struct foo * make_another_foo (void);
extern void use_another_foo (struct foo *);

void bar(void) {
  struct foo * f1, *f2;

  f1 = make_a_foo (void);
  f2 = make_another_foo (void);
  use_a_foo (f1);
  use_another_foo (f2);
}

where the two 'struct foo's are different in the translation units
that implement make_a_foo and make_another_foo, and then have all four
routines inlined into 'bar' so that 'bar' needs to see both versions
of the structure.  Of course, in a real program it wouldn't be done in
such a bare-faced fashion; bar() itself might have been constructed
through inlining, for example.

Worse, you might see this file first, so you won't know about the
problem until later in parsing, which will be after you've already
unified the declarations in this file.

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