This is the mail archive of the
mailing list for the GCC project.
Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility
- From: Joe Buck <Joe dot Buck at synopsys dot com>
- To: austern at apple dot com (Matt Austern)
- Cc: gcc at gcc dot gnu dot org, rth at redhat dot com, bkoz at redhat dot com
- Date: Fri, 2 Aug 2002 15:06:10 -0700 (PDT)
- Subject: Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility
Matt Austern writes:
> An ABI test suite is a good idea. Ultimately, of course, the real
> test is the one users care about: can I generate a DSO (or, more
> generally, an object file) with an old compiler, and link it to
> something generated with the new compiler? That's the whole
> point of ABI stability.
The GNU C++ policy up to this point has been to insist at least that
minor releases be binary-compatible, for both the compiler and the
standard library. We've been working towards freezing things on
larger scales as well.
> Preventing intentional ABI changes is less a technical issue than
> a management decision. Look at how Sun has maintained a
> stable C++ ABI, for example.
Ouch. Sun has not succeeded nearly as well as your message suggests:
because of problems with their standard library implementations, in many
cases they've broken binary compatibility even with bug fix patches,
multiple times. Projects I've been on have been burned badly by this.
> 1. They [Sun] decided that ABI stability was more important than
> correctness. They decided that they will not fix certain kinds
> of bugs, if bug fixes would break compatibility.
> 2. They decided that they would not release a compiler with
> something that they called a frozen ABI until they'd tested it
> thoroughly enough that they'd be sure there weren't many
> such bugs.
I'm sure that this was their policy, but they did not execute it
completely successfully. They were particularly bad in the 5.x
days. I suspect that they've learned their lesson and have better
processes in place now.
> My impression is that we're not yet ready to make decision #1, that
> at this point we still think correctness is more important than
Actually, speaking as just one SC member, I'm pretty close to making
decision #1, in the following sense: we put out gcc 3.2, and a number
of GNU/Linux and BSD distributions go to it. Result: we have binary
compatibility across the free-OS space. But later it turns out that we
interpreted some part of the spec differently than some other compiler
developer. I'd be inclined to just leave it, and document the
differences, unless the bad interpretation results in code that
Note that one of the 3.1.1 -> 3.2 ABI changes falls in this category: not
only does the erroneous implementation disagree with the spec, but the
result is that certain programs will malfunction. At this point, I would
resist changes in the ABI that aren't as serious as this.
(This is the case where we derive from a POD, and put new members into
the POD's padding. Passing a pointer to the base class to C code is
likely to result in members of the derived class getting overwritten).
But, you say, this might mean that we aren't binary compatible with some
proprietary compiler. Maybe so, but that will just be the proprietary
compiler vendor's problem: if GNU compatibility is important to them,
the work will be on their shoulders to achieve it. We did the best we
> I also don't have the impression that we're ready yet to
> make decision #2; I don't think anyone wants to delay the 3.2 release
> for six months worth of testing. Am I right about both of those
In order to get the agreement that we have gotten, that distribution
vendors will re-unify around an official GCC release (and get rid of the
current situation with "2.96" versus egcs versus 2.95.x versus 3.0 etc),
we don't have much room to delay 3.2. A delay would mean that people
would start using 3.1.1 for production, or doing their own patches to make
a 3.2-that-we-now-have equivalent, delaying the window for
cross-distribution C++ ABI reunification for another year at least.
So, in summary: you're right, there may be another bug in 3.2's
implementation of the ABI. But if so, I would recommend that we respond
by just documenting the bug.