This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

C++ ABI: Tail padding


[Resent with correct address for ABI mailing list in headers.]

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


--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]