This is the mail archive of the 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]

Re: C++ ABI Issues

I wrote:
> Finally, there's the issue of how far we bend over to make it easier to
> accomodate the proprietary competition to GCC on GNU/Linux.  That is, who
> are we doing this ABI for?  Describing GCC so precisely so that it can be
> easily replaced?  Mind you, I *do* want good documentation and adherence
> to standards, and I'm against the introduction of any artificial barriers,
> but the distributors really, really wanted a release that would re-unify
> the world and we gave it to them.  Maybe the best thing in the short term
> is for the competition to release patches to make their compilers
> bug-compatible with GCC.

While I don't really think that the last sentence is *really* what should
be done, note that this isn't unprecedented.  For years, there were a
number of deviations between Berkeley's TCP/IP stack and the RFC's, but
most people ran Berkeley's code (even Microsoft), so the world had to be
compatible with the bugs.

David Edelsohn writes:

> 	I think it is highly arrogant if GCC says that the ABI is whatever
> we implemented.  There is an external ABI specification.  G++ claims that
> it follows the spec.  Other proprietary compilers implementing the ABI
> were able to get these cases correct without an external conformance
> testsuite.

While the other vendors may have gotten these two cases correct, how do
you know that they haven't made other errors?  That is, are you certain
that no bugs will be discovered in their conformance?

>  Acting as if the entire world revolves around GCC will not
> elicit much respect for GNU/Linux and GCC from the marketplace.

The GCC 3.2 ABI is what it is.  We shipped the thing.  Saying so isn't
arrogant, it is simply a fact.  We did our best, and there are bugs.  If
you ask Intel whether they will legally warrant that their compiler
matches the spec in all respects, they will decline, as they should.  No
one can make such a promise.

Should we simply withdraw GCC 3.2 at this time, after making promises to
various distributors about it, we will do even more damage.

We will, eventually, need to fix the ABI.  But we should not rush to do
so.  Instead, I proposed to add warnings for areas where we don't match
the spec.

As for "respect from the marketplace": I know of a number of people who
have communicated internally to their organizations that 3.2 was going to
have a stable ABI that would stand up for a while (I was one of them, and
I wasn't alone).  Take that away, and you will do vastly more damage to
GCC's credibility than if you insist that we keep yanking releases and do
3.3, 3.4, 3.5, 3.6 until it works just like Intel's compiler.

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