Dealing with C++98/11 ABI incompatibilities

[Jason Merrill]

There seem to be two areas of concern with compatibility between the 
C++98 and C++11 ABIs:

1) Changes to member function return types, as with std::complex.  For 
these, the two functions could coexist except that they are mangled the 
same way.  So I propose that we introduce a mechanism to change the 
mangled name of a member function.  Unlike with attribute ((alias)), the 
declared name would only be visible at the source level, not in the 
assembly output.

My inclination is to just have a single declaration and have an 
attribute to change its name for linkage purposes.

In the passed we have discussed using inline namespaces to do this sort 
of renaming, but that doesn't help with individual member functions 
within a class, like the situation in std::complex.

2) Object layout changes to std::list and std::basic_string.  For these 
types, there is no way to both retain backward compatibility with older 
C++98 code and conform to the C++11 standard.  The best we can hope for 
is to allow old code to coexist with new code so long as they don't try 
to touch the same string/list objects.

As above, one solution to this would be to change the linkage name of 
the new versions so that they don't clash with the old versions.  But 
that isn't enough in this case, as it wouldn't affect the linkage name 
of a class like

struct Wrap { std::string s; };

so we would need some way to cause the name decoration to propagate to 
other containing/derived classes.

It seems that ELF symbol versioning could be useful for this purpose. 
If we were to extend the visibility attribute to also handle symbol 
versions, that could handle a lot of issues.  If Wrap uses the GLIBCXX_4 
version of string, then Wrap would also be marked with the GLIBCXX_4 
version, and any functions that deal with Wrap would be marked with that 
version, and so on.

I'm not familiar enough with the intricacies of ELF versioning to be 
confident that this would work; is anyone else?  In particular I'm not 
sure how the interaction of versioned and non-versioned code will work.

Jason