Re: [PATCH] C++ space optimization: de-cloning con/de/structors

[Matt Austern <austern at apple dot com>]

On Wednesday, August 7, 2002, at 02:34 PM, Stuart Hastings wrote:

> On Tuesday, Aug 6, 2002, at 16:24 US/Pacific, Jason Merrill wrote:
>
> > On Tue, 6 Aug 2002 11:41:49 -0700, Stuart Hastings <stuart@apple.com> 
> > wrote:
> >
> > > This patch essentially un-does the cloning operation.
> > This seems like a reasonable thing to do, though Mark's point about
> > alternate entry points is a good one.
> >
> > Also, the unified *structors should have internal linkage to avoid 
> > any ABI
> > impact.  Then this just becomes an implementation detail.
> I haven't experimented with this; we had some serious misery when our 
> coalesced EH info records got slightly different linkage than their 
> functions, so we're pretty gun-shy about tweaking linkage.  :-P
>
> I asked Matt Austern (conveniently in the adjacent office :-), and he 
> asked: Is private linkage appropriate for unified constructors invoked 
> by "static inline" or "template" constructor thunks?  (Sorry, that 
> question is a mouthful.)
Sorry, I should've just asked this myself.  My question wasn't about 
static
inlines, but about extern inlines (the default).

The problem, of course, is that we might have an inline (or template)
constructor in multiple translation units; we're required to only have
a single copy after we do the link.  Would this conflict in any way with
giving constructor bodies internal linkage?

Genuine question, not a rhetorical one.  I don't remember whether
the usual vague linkage mechanism depends on external linkage.
With Apple's linker the issues are related; I don't know if that's true
for other linkers.

			--Matt