This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ ABI issues
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: gcc at gcc dot gnu dot org, jason at redhat dot com
- Date: Mon, 18 Mar 2002 10:26:06 -0800
- Subject: Re: C++ ABI issues
Hey Jason. I've been wondering about this myself. One of the things I
think might be helpful, when thinking about this, would be a detailed
list of ABI changes between gcc-3.0.4 and gcc-3.1.0. I've noticed that
you have started marking ABI-changing patches explicitly: thank you
very much for this, it's very illuminating. I could come up with a
list of library changes, if that would be helpful.
I'm not as up on this stuff as yourself, but it appears as if the
following are a subset of the things that have changed in the FE:
- pointers to cv-qualified member functions
http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01363.html
- c++/3948
run destructors for value parms in the caller, pass params by invisible ref
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01056.html
- 128-bit ints
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00761.html
In addition, it appears as if non-C++ FE work has ABI impacts for some targets:
- mips o32 ABI
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00706.html
> One answer would be to bump the mangling version for non-ia64 targets,
> so that incompatible code will fail to link.
Why just non-ia64 targets?
Won't the major version number change from .3 to .4 in libstdc++-v3
also prevent linkage?
I'd feel better if there was a better mechanism for testing the C++
ABI. Thoughts?
In a related note, there doesn't seem to be a plan in place to test
the C++ library versioning. Even if it's not documented, it would be
nice to have some procedure that's documented.
best,
benjamin