libstdc++ PATCH to add abi tag to complex::real/imag

As mentioned in http://gcc.gnu.org/wiki/Cxx11AbiCompatibility, C++11 
changes the return type of complex::real and imag, leading to a binary 
incompatibility between C++98 and C++11 code if the functions are used 
without inlining.  This patch adds an ABI tag to the C++11 variants so 
that they have different mangled names.  This does not change the 
exports from libstdc++.

For the map void->iterator change, I think it would make sense to just 
unconditionally return an iterator; there's no binary compatibility 
issue with older code that expects it to return void, the problem is 
only with C++11 code calling a C++98 instantiation that returns void.

For the other cases mentioned on that page, I think either we want to 
unify the two implementations (because we think they're compatible) or 
add ABI tags to the C++11 implementations.

Is this patch OK for trunk?  Does someone on the library team want to 
look at the other cases?

On Sat, 10 Nov 2012, Jason Merrill wrote:

> As mentioned in http://gcc.gnu.org/wiki/Cxx11AbiCompatibility, C++11 changes 
> the return type of complex::real and imag, leading to a binary 
> incompatibility between C++98 and C++11 code if the functions are used 
> without inlining.  This patch adds an ABI tag to the C++11 variants so that 
> they have different mangled names.  This does not change the exports from 
> libstdc++.

It looks like it won't prevent from using ref-qualifiers when they are 
implemented if we want to (PR 51013), which is good.

> For the map void->iterator change, I think it would make sense to just 
> unconditionally return an iterator;

It does break C++98 code that does "return f();" in a function returning 
void, but that's negligible.

> there's no binary compatibility issue 
> with older code that expects it to return void, the problem is only with 
> C++11 code calling a C++98 instantiation that returns void.

That's going to happen in practice, isn't it? So do you mean to add the 
abi tag to this unified function, for safety?

On 11 November 2012 02:27, Jason Merrill wrote:
>
> Is this patch OK for trunk?  Does someone on the library team want to look
> at the other cases?

The patch looks good to me. Thanks for implementing the attribute.

I'll start looking at some of the other cases.

For std::list I assume we want the attribute on the type itself, not
just member functions, since its size changes.

For vector::data() we should be able to make the attribute conditional
on is_same<_Tp*,allocator_type::pointer> so it doesn't change mangling
unless necessary.

As well as the existing incompatibilities, I need to add a new virtual
function to support returning future_status::deferred from
std::future::wait_{for,until}.  Is it appropriate to use the same
"cxx11" tag for that too, even though the existing implementation is
also "cxx11" because the type wasn't in C++98?   Or do we want to use
a different tag, such as "cxx11v2" or just "v2"?

Hi,

On 11/11/2012 12:55 PM, Jonathan Wakely wrote:
> On 11 November 2012 02:27, Jason Merrill wrote:
>> Is this patch OK for trunk?  Does someone on the library team want to look
>> at the other cases?
> The patch looks good to me. Thanks for implementing the attribute.
>
> I'll start looking at some of the other cases.
>
> For std::list I assume we want the attribute on the type itself, not
> just member functions, since its size changes.
If it's that easy, I can do this bit, ie, simply restore my old patch, 
which was already complete and tested.

Of course thanks a lot from me too!

Paolo.

On 11/11/2012 06:55 AM, Jonathan Wakely wrote:
> For std::list I assume we want the attribute on the type itself, not
> just member functions, since its size changes.

Yes.  Note that I believe for the list and string changes we want to 
change the default ABI for C++98 and C++11, not just C++11.  And provide 
a way for users to select the old ABI if they need to pass string/list 
objects to and from previously compiled code.

> As well as the existing incompatibilities, I need to add a new virtual
> function to support returning future_status::deferred from
> std::future::wait_{for,until}.  Is it appropriate to use the same
> "cxx11" tag for that too, even though the existing implementation is
> also "cxx11" because the type wasn't in C++98?   Or do we want to use
> a different tag, such as "cxx11v2" or just "v2"?

If this is a C++11-only class, then I don't think we need a tag at all. 
  I don't think we've been trying to maintain binary compatibility 
between major releases for C++11 code.  The goal of all of this is to 
allow old C++98 code to coexist in the same running program with new 
C++11 code so long as they aren't trying to use the same string/list 
objects.

Jason

On Sun, 11 Nov 2012, Jason Merrill wrote:

> On 11/11/2012 06:55 AM, Jonathan Wakely wrote:
>> For std::list I assume we want the attribute on the type itself, not
>> just member functions, since its size changes.

When we are changing the whole type, I assume the point of using this
attribute instead of the standard solutions (move it to some other
(inline) namespace, for instance) is the -Wabi-tag warning?

> Yes.  Note that I believe for the list and string changes we want to change 
> the default ABI for C++98 and C++11, not just C++11.  And provide a way for 
> users to select the old ABI if they need to pass string/list objects to and 
> from previously compiled code.

That way is already needed while building libstdc++, and we need to 
compile all files that use string twice during the build, exporting only 
the symbols that contain "cxx11" from one of the builds.

Changing string/list is still an ABI break. Is it for 4.8, or should it 
wait until 4.9?

On 11/12/2012 01:50 AM, Marc Glisse wrote:
> When we are changing the whole type, I assume the point of using this
> attribute instead of the standard solutions (move it to some other
> (inline) namespace, for instance) is the -Wabi-tag warning?

Right.

Jason