This is the mail archive of the
mailing list for the GCC project.
Re: [www-patch] bugs.html rewrite,part 6: section about upgrading the compiler
- From: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- To: Richard dot Earnshaw at arm dot com
- Cc: gp at suse dot de, gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Nov 2003 14:48:23 +0100 (CET)
- Subject: Re: [www-patch] bugs.html rewrite,part 6: section about upgrading the compiler
- Reply-to: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
On 19 Nov, Richard Earnshaw wrote:
>> On Wed, 19 Nov 2003, Volker Reichelt wrote:
>> > Well, the sentence would get way too long for my taste (about 4 lines in
>> > the HTML source). I'd rather suggest the following:
>> > + <h4>ABI changes</h4>
>> > +
>> > + <p>The application binary interface (ABI) defines how the elements of
>> > + classes are laid out, how functions are called, how function names are
>> > + mangled etc. It usually changes with each major release (i.e. when the
>> > + first or second part of the version number changes). You <em>must</em>
>> > + recompile all C++ libraries, or you risk linker errors or crashing
>> > + programs. However, the ABI is not changed with bug-fix releases (i.e.
>> > + when the third part of the version number changes). The code should be
>> > + binary compatible among these versions.</p>
>> I like that one; it's much better than what I suggested. ;-)
> While this has been historically true, the whole point of having a defined
> ABI is to avoid the need to do this at every turn of the wheel.
> I'm not sure we should be expressing our short-commings in this way, even
> if it is a reflection of what's happened in the past.
Well, theoretically you're right: There should be only one ABI.
But bugs.html is a trouble-shooting page for real problems of
(non-expert) users. And I think we should be fair and warn them
of potential problems.
The old version of bugs.html stated:
| <p>GCC 3.0 had a new ABI, which affected class layout, function mangling and
| calling conventions. We had intended it to be complete, but unfortunately
| some issues came to light, too late to fix in the 3.0 series.
| The ABI should not change in dot releases, so we addressed most issues
| in GCC 3.1.</p>
But the same holds for the transition to 3.2 (which was done only
because of ABI flaws) and to 3.3 and possibly to 3.4. Just continuing
this list doesn't make much sense to me. So I (with help of others, but
I'll take the blame) chose this wording to reflect of what's happened in
What would be your suggestion (that fits into 3 or 4 sentences)?