[PATCH] libstdc++ ABI issues with __int128

[Jakub Jelinek]

On Sun, Mar 20, 2011 at 01:58:24AM +0100, Benjamin Kosnik wrote:
> 2011-03-19  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* config/abi/pre/gnu.ver (CXXABI_1.3): Don't export _ZT[IS][PK]*[no].
> 	(CXXABI_1.3.5): Export _ZTI[PK]*[no].
> 
> This looks good to me, nice catch. I'll figure out what happened with
> check_abi when I'm back, conductivity-wise.

For _ZTSn etc. I think this shouldn't be a problem, as from what I can see
_ZTI* for builtin types lives just in libstdc++/libsupc++ and thus it should
be sufficient to export _ZTI* (unless somebody links -lsupc++ or libstdc++.a into
dynamically linked code, but that would be user error).

> And:
> 
> > And another question is, we still export a bunch of new _ZTS* symbols, isn't
> > that now pointless when we always do strcmp anyway?
> 
> Yes, indeed it is as long as  !__GXX_TYPEINFO_EQUALITY_INLINE &&
> !__GXX_MERGED_TYPEINFO_NAMES for all targets that have baseline
> symbols. I think that is correct, since they are all linux targets.
> But arm-linux too?

Most of the linux targets are actually __GXX_TYPEINFO_EQUALITY_INLINE 1
and thus perhaps if we want to maintain some ABI compatibility with 3.4-ish
inlined typeid comparisons, we might need to export _ZTS* for _ZTI*
that could somehow be emitted for user code too.

Thus perhaps the _ZT[IS][PK]*[no] change is right, but we can only do it
only for the builtin types (and, clearly we've been doing that in the past,
for decltype(nullptr)/_Decimal{32,64,128}/char{16,32}_t.

If/when we decide to break ABI for C++, we could just make all _ZTS* symbols
hidden.

	Jakub