C++ ABI Issues

[Mark Mitchell <mark at codesourcery dot com>]

Our testing and investigation has lead to the discovery of several places
where G++'s class layout still does not match the published ABI
specification.  Other vendors (notably HP and Intel) do match the ABI
specification.  Therefore, the ABI specification is probably not going
to change to validate G++'s behavior.

Therefore, we will have to choose whether or not we want to change G++
to match the specification.

Here are the issues:

1. Tail-padding of bit-fields

  Given:

    struct B { virtual void f(); char i1 : 28; };
    struct D : public B { int i2 : 4; };

  G++ incorrectly packs D::i2 into the four bits of tail-padding in
  B.

  This is not only an ABI divergence, but also an optimization issue.
  G++ generates a copy-constructor for B that performs the bit-masking
  operations required to copy only the bitfield at the end of B, which
  is more expensive than copying the entire word.

2. Tail-padding and virtual base classes

  Given:

    struct A { virtual void f(); char c1; };
    struct B { B(); char c2; };
    struct C : public A, public virtual B {};

  G++ does not pack B into the tail padding of A, as required by the ABI
  specification and as implemented in other compilers.

  G++'s behavior is slightly wasteful of space, but is otherwise correct
  in the abstract.

My expectation is that case 1 is relatively uncommon, but that case 2 is
relatively common.

I propose that we fix G++ to match the ABI, but that we issue warnings
about classes whose layout has changed from GCC 3.2.

If we are going to fix G++, we also have to decide how urgently to do
another release.

Thoughts?

(The flame you're about to send about the fact that we didn't catch this
before GCC 3.2 isn't helpful.  Until we have a comprehensive testsuite
(in the works, as discussed), it's very hard to find these things.  And,
even then, there may be issues.  Several free software distributors pushed
hard for a GCC 3.2 release, and everyone knew that there might be more
problems.)

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