Re: C++2a synchronisation inefficient in GCC 11

[Jonathan Wakely <jwakely@redhat.com>]

On 26/02/21 09:37 -0800, Thiago Macieira via Libstdc++ wrote:
>On Friday, 26 February 2021 03:19:02 PST Jonathan Wakely wrote:
>> > has huge inefficiencies. Since everything in this implementation is
>> > inline and, once released, it will tie our hands until the next ABI break
>> > (libstdc++.so.
>> That's not true. By not committing to exporting these symbols from
>> libstdc++.so now, we can move them into the library later once the
>> design is stable.
>
>Hello Jonathan
>
>Thank you for replying.
>
>The problem is not the export or not export, it's that the protocol/method is
>locked down. We cannot change it in a future version, like changing the number
>of __waiter objects in the __waiters::_S_for function. Since that code gets
>inlined into every executable that uses it, future versions are bound to use
>the exact same selection until we break ABI.

Compiling C++20 code with GCC 11 and linking to C++20 code compiled
with GCC != 11 is unsupported. The ABI is expected to break for C++20
features.

We can change it. We WILL change it.

The world is not ending.

>> C++20 support is experimental and not stable. If you compile it with
>> GCC 11 you can't expect to link it to C++20 code compiled with GCC 12.
>> So for GCC 12 (or a later version) we could replace the inline
>> functions with non-inline code in libstdc++.so and commit to that
>> being stable.
>
>Oh? That's not a really widely understood fact. I see people using C++20 right
>now all the time in the cpplang slack and no one seems to be worried that
>support is experimental.

I can't really help it if people don't read documentation for
important tools they rely on.

https://gcc.gnu.org/projects/cxx-status.html#cxx20

https://gcc.gnu.org/gcc-8/changes.html#libstdcxx
https://gcc.gnu.org/gcc-9/changes.html#libstdcxx
https://gcc.gnu.org/gcc-10/changes.html#libstdcxx
https://gcc.gnu.org/gcc-11/changes.html#libstdcxx