This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C++ ABI: Reuse of tail padding
- From: Mark Mitchell <mark at codesourcery dot com>
- To: c++-abi-dev at codesourcery dot com, gcc at gcc dot gnu dot org
- Cc: jason at redhat dot com, nathan at codesourcery dot com
- Date: Wed, 14 Aug 2002 13:53:38 -0700
- Subject: C++ ABI: Reuse of tail padding
It looks like the ABI document meant to require the reuse of tail-padding
in non PODs, but it doesn't actually say that.
Consider this case, as the canonical example:
struct S1 {
virtual void f();
int i;
char c1;
};
struct S2 : public S1 {
char c2;
};
I think the ABI meant to say that you put "c2" in the tail padding for
S1. (That is what G++ implements, FWIW.)
However, the ABI doesn't actually say that. Walking through section 2.4
of the ABI, we first layout S1. Let's assume 32-bit pointers and "the
usual" alignment rules. Since nvalign(S1) is 4, we set nvsize(S1) to 12:
After all such components have been allocated, set nvalign(C) = align(C),
and set nvsize(C) to the least multiple of nvalign(C) that is greater
than or equal to dsize(C).
Having done that, we're not going to make use of the tail padding. If
we want to make use of tail padding, we have to not round up nvsize(S1).
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. The latter claim is in conflict with the layout
algorithm as quoted above. Furthermore, "dsize(0) minus the size of
virtual bases" isn't really very clear; that sounds like
"dsize(O) - sizeof (V1) - sizeof(V2)..." which is not necessarily
the same as the part of O that does not contain virtual bases or tail
padding.
We have a problem here.
Intel's compiler does not pack things into the tail padding.
Neither, I expect, does HP's.
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 I would prefer to change G++, and drop this idea from the spec,
even though it is an optimization.
Thoughts?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com