[cxx-abi-dev] C++ ABI version 2

[John McCall]

On Nov 21, 2013, at 12:41 AM, Marc Glisse <marc.glisse at inria.fr> wrote:
> On Wed, 20 Nov 2013, John McCall wrote:
>> Well, to be clear, these would be recommendations for people willing to endure an ABI break.  That would still be a big NO-NO for any established platforms that care about binary compatibility.
>> 
>> And most of these changes are pretty minor improvements; the ABI has really held up very well.
> 
> Indeed.
> 
>>> Maybe revisit some old issues?
>>> 
>>> A-9 has the comment: "this won't happen often", but it affects sizeof(tuple<tuple<int>>) in libstdc++. Hmm, no, it doesn't, but it would if they swapped the order of their bases (currently for tuple<int,unsigned> they store the unsigned before the int). Of the 3 permutations tuple<int,E,E>, tuple<E,int,E> and tuple<E,E,int> where E is empty, only 1 has a small size, whereas I believe at most 1 should be large (0 would be great). And that's not the only place I've hit this.
>>> 
>>> A-5: gcc and HP seemed to find it hard to implement at the time. Would that still be the case? (it may need to mention move constructors now)
>>> I seem to be missing the detail that makes it so complicated.
>> 
>> I am not sure how to interpret these comments.  Would you mind translating them into HTML #entity references, or at least section numbers, of the living document at:
>> http://mentorembedded.github.io/cxx-abi/abi.html
> 
> A-5, A-9 were references to the issue list:
> http://mentorembedded.github.io/cxx-abi/cxx-closed.html#A9
> (A-5 has no anchor but is easy to find)

Oh, I should have recognized that, sorry.

> A-5 is about section 3.1.3 #empty-parameter, where we could omit some empty arguments passed by value.

Empty structs are a reality in C: an extension, to be sure, but a common one and thus a reality.  We should defer to the psABI.  Platform compiler vendors can define the problem away for themselves however they please.

> A-9 is about section 2.4.II.3 #class-types, where if offset 0 fails we don't try offset nvalign(D), 2*nvalign(D), etc but jump straight to dsize(C).

Ah, yes, that seems like a reasonable thing to change, although I think it increases the complexity of actually implementing that quite a bit.

John.