3.1/3.2 C++ ABI change

[Matt Austern <austern@apple.com>]

Consider the following snippet:
      struct VBase {
        int n1;
        virtual ~VBase();
        virtual void f();
      };

      struct Derived : public virtual VBase {
        int n2;
        virtual ~Derived();
        virtual void g();
      };

      VBase::~VBase() { }
      Derived::~Derived() { }

With gcc 3.1, the beginning of Derived's vtable is:
_ZTV7Derived:
         .long   8
         .long   0
         .long   _ZTI7Derived
         .long   _ZN7Derived1gEv
         .long   _ZN7DerivedD1Ev
         .long   _ZN7DerivedD0Ev
         .long   0
         .long   -8
         .long   -8
         ...

With 3.2, on the other hand, these entries are:
_ZTV7Derived:
         .long   8
         .long   0
         .long   _ZTI7Derived
         .long   _ZN7DerivedD1Ev
         .long   _ZN7DerivedD0Ev
         .long   _ZN7Derived1gEv
         .long   0
         .long   -8
         .long   -8
         ...

My understanding is that this was an intentional change, because the
implementation of the ABI was incorrect in 3.1.  My understanding, in
fact, is that this was the whole point of the 3.2 release: there are 
very
few differences between 3.1 and 3.2 other than this ABI-breaking
change.  System vendors were encouraged to ship 3.2, which was
hoped to have a more stable C++ ABI.  Correct so far?

(If I'm wrong on the above, and if this vtable change is just a bug,
please correct me.)

The problem, of course, is that Apple shipped 3.1 as our system
compiler.  We're trying to figure out what to do next.  It looks like
there's some machinery in the compiler that lets users ask for
ABI compatibility with earlier compiler versions.  It also looks like
it's incomplete, and that it doesn't cover this particular vtable layout
change.

So,...
(1) Was it the intention behind the ABI compatibility switch that it
should cover this vtable change?
(2) If Apple provided code allowing C++ ABI compatibility with 3.1,
would people be interested?

			--Matt