[cxx-abi-dev] Non-cloned [cd]tors

[Dennis Handly]

>From: "de Dinechin, Christophe (Integrity VM)" <christophe.de-dinechin at hp.com>
>Shouldn't we at least attempt to explain the rationale of how this is
>supposed to work if the compiler for the derived class and base class
>are different?

Yes.  But it may be too late, other than list other implementations?

>It breaks easily, say if one of the compilers optimizes away an "unneeded"
>constructor from one of the COMDATs.  So we need to make it clear why a
>compiler must emit constructors that it doesn't need.
Christophe

Yes.

>From: Jason Merrill <jason at redhat.com>
>A quick check with icc 10.1 shows that they currently put them in 
>separate COMDATs as well.  And they also emit a C9/D9 variant, curiously 
>enough.  Anyone know what that's for?

That was that common function Steve and I mentioned.

>I want to fix both G++ and the ABI, which seems to require the G++ 
>implementation:
>"Implicitly-defined or inline user-defined constructors and destructors 
>are emitted where referenced, each in its own COMDAT group identified by 
>the constructor or destructor name."

At least this is simple.  Except how to mangle it.  And since the mangling
of these has a C# or D#, which to pick?

>what name should we give the common comdat group?  [CD]5, perhaps? 
>We can't use one of the existing names, so we can't just adopt the HP 
>compiler convention.

You could but we do it two different ways.  :-)

>Do we want to treat inlines differently from non-inline templates?  I 
>think not.
Jason

Right, they are the same, both need comdats.

>From: "J. Stephen Adamczyk" <jsa at edg.com>
>On the larger issue, I can confirm that we do put each entry point  
>into a COMDAT named the same as the routine.

I assume this could easily be changed with some conditional compilation to
maintain compatibility for existing implementations, if desired.