On Nov 21, 2013, at 12:41 AM, Marc Glisse <[email protected]> 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. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
