Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> Is there a more detailed description of what the known
> incompatibilities are, and/or what C++ features might
> trigger them, and/or whether there is a subset of C++ that
> one might reasonably expect to work compatibly, say from
> egcs 1.1 to gcc 2.95?

I started collecting such information, but I don't know whether my
list is complete. If anybody has additions, please let me know:

- STL was updated. In particular, the Allocator implementation was
  replaced, and renamed. As a result, all mangled names mentioning
  an allocator (i.e. more or less *all* instantiations of standard
  templates) are binary-incompatible with egcs 1.1. As STL continues
  to evolve in a binary-incompatible manner, such changes are likely
  in the future.
  A number of other STL classes changed as well. I stopped writing
  down the changes when I noticed the allocator thing; feel free to
  diff between 1.1 STL and 2.95 STL if you need more details.
- __start_cp_handler was introduced as part of libgcc, and the EH
  machinery. The old (i.e. 1.1) functions remain present, and it
  is ok to mix them with __start_cp_handler. It only means that you
  cannot link 2.95 object files with the 1.1 libgcc.a

Anything else should be compatible. As I said, I may be missing
things. Since people will continue to ask this question: If anybody
knows of any other incompatibility, *please* let me know.

As for compatibility with even older versions (egcs 1.0, gcc 2.8):
Forget it. I have no complete list, but the changes to make EH
thread-safe should break a large number of binaries; I believe STL was
updated between 1.0 and 1.1, as well.

> And is there anything describing likely C++ ABI changes in
> near-future releases (2.9x for x > 5; and/or 3.0)?

Well, it is very easy to find out what *currently* comprises the ABI
changes in gcc 2.96, under the -fnew-abi flag; see cp/decl2.c for a
details:
- The squangling mechanism will break link compatibility.
- honor-std breaks that as well, at least for std library things
  (primarily iostreams and STL)
- vtable-thunks are enabled on all platforms (under new ABI), with
  an important fix still missing (but coming up)
- the new ABI itself currently does the empty bases optimization,
  but different people have different ideas what else it could or
  should do.

If the above counts as "anything", I guess I'm done. It is difficult
to tell what changes exactly will be in the next compiler, especially
as I did not mention libstdc++ v3 so far. If we get that, about every
program using the std library will binary-break.

So it is a safe bet that one of the upcoming releases will be totally
incompatible with anything you are compiling right now. Exactly *when*
this will happen is open at this time; different people have different
views :-)

Hope this helps,
Martin

P.S. I didn't include any sales talk about how great the future will
be, and how important it is to give the new features to the users, and
that users should either accept that as a fact of life, or continue
with the compiler they got. I hope you'll understand all this, anyway,
and that I'm speaking for myself, not as a representative of somebody
or something.