C++ ABI: Tail padding

[Jason Merrill]

On Wed, 14 Aug 2002 13:56:08 -0700, Mark Mitchell <mark at codesourcery.com> wrote:

> I think the ABI meant to say that you put "c2" in the tail padding for
> S1.  (That is what G++ implements, FWIW.)

Yes, that's my recollection from the meetings.

> Section 2.1 says that nvsize is "dsize(O) minus the size of virtual
> bases", and the claim is made that nvsize(C) == dsize(C) for classes
> without virtual bases.

So the algorithm is in conflict with the clearly stated intent.

> We have a problem here.

Yep.

> Intel's compiler does not pack things into the tail padding.
>
> Neither, I expect, does HP's.

I'm not so sure.  HP were present at the ABI meetings, so they were at
least exposed to the intent, though I don't think Christophe was
implementing the class layout.

Can someone please check the behavior of the HP compiler?

> G++ is supposedly within hours of a supposedly ABI-stable release.

> Technically, the G++ version is superior.  (It reduces space used by
> objects.)  On the other hand, it was basically impossible for
> implementors to figure out what was intended from the spec.

I think that the stated intent in 2.1 is quite clear, as is the
contradictory algorithm.

> I think I would prefer to change G++, and drop this idea from the spec,
> even though it is an optimization.
>
> Thoughts?

OK, here are some:

Dropping this optimization would not make a compliant compiler
significantly less complex.  In G++, handling this is a generalization of
empty base support.  If we were going to drop an optimization, I'd vote for
the notion of primary virtual bases...:)

Nathan asks how often the optimization would occur in real programs.
Judging from the OpenOffice workarounds for our until-recently-buggy
handling of tail padding, it does occur.  We could also conclude that users
find it somewhat surprising.

I'm not irrevocably attached to the optimization, but the ABI document
seems to have one vote for and one against, likewise the compilers surveyed
so far.

G++ can (and already does) change its ABI in the 3.2 release; after that it
will be much harder.  From recent list traffic, HP's compiler is known to
have vtable layout bugs, so presumably they can also change their ABI if
necessary.  I don't know whether the Intel compiler has any known ABI bugs.

I don't feel strongly about this question.  I'm willing to let the HP
compiler break the tie.

Jason