From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-61211-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10710 invoked by alias); 7 Oct 2002 21:05:51 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 10703 invoked from network); 7 Oct 2002 21:05:50 -0000
Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51)
  by sources.redhat.com with SMTP; 7 Oct 2002 21:05:50 -0000
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g97L5os18993
	for <gcc@gcc.gnu.org>; Mon, 7 Oct 2002 14:05:50 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5dcb95cb31118164e13cc@mailgate2.apple.com> for <gcc@gcc.gnu.org>;
 Mon, 7 Oct 2002 14:05:50 -0700
Received: from isolde (isolde.apple.com [17.201.24.249])
	by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g97L5nV26953
	for <gcc@gcc.gnu.org>; Mon, 7 Oct 2002 14:05:49 -0700 (PDT)
Date: Mon, 07 Oct 2002 16:11:00 -0000
Mime-Version: 1.0 (Apple Message framework v543)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: 3.1/3.2 C++ ABI change
From: Matt Austern <austern@apple.com>
To: gcc@gcc.gnu.org
Content-Transfer-Encoding: 7bit
Message-Id: <D34692B2-DA38-11D6-AC60-00039390D9E0@apple.com>
X-SW-Source: 2002-10/txt/msg00435.txt.bz2

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