C++2a synchronisation inefficient in GCC 11

[Ville Voutilainen]

On Sat, 27 Feb 2021 at 02:11, Thiago Macieira <thiago.macieira@intel.com> wrote:
>
> On Friday, 26 February 2021 15:58:01 PST Ville Voutilainen wrote:
> > > Should they also prevent people from compiling their code with GCC 11,
> > > which will define the macro and does support "-std=c++20"?
> >
> > Yes, if there's an implementation bug in GCC 11 that renders the GCC
> > 12 implementation incompatible.
> > This is not new.
>
> One would expect that implementation bugs -- not design flaws -- do not affect
> the entire functionality. And in most inline code, that is not a big deal
> since the operation was still achieved one way or the other.
>
> What we're talking about here makes the entire set of classes unsuitable for
> consumption and dangerous, with no way to programmatically determine when
> they've become suitable. My worry is not that someone will rush to use them in
> 2021. My worry is that well-tested code in 2024-2025 breaks because people are
> using a mix of systems that includes Ubuntu 22.04.

There's nothing new in that either. I do, however, wonder how
dangerous using the current
implementation actually is? Anyhoo, almost regardless of that, we have
had situations like
that before. While we don't exactly want to repeat them (std::regex
in.. gcc8? comes to mind here),
I'm not entirely convinced that we are talking about a showstopper problem here.

> > No general one. Here we are talking about implementation bugs;
> > feature-testing macros are not
> > trying to cover those. And in the sunshine cases where we don't have
> > bugs or binary breaks,
> > defining the macros early is fine, so we're not going to postpone
> > defining them, in the hypothetical
> > event that someone might suggest that.
>
> Fair enough, but we know we are not in the sunshine case. We know now, before
> the release, that it WILL change and cause silent incompatibilities. Does that
> change the conclusion?

Do tell me what those silent incompatibilities really are. If they're
differences in inlined
code baked into client applications, I'm not sure I see what's so
earth-shattering there.

> How about the other way around: only enable the new, experimental code if the
> user defines _GLIBCXX_I_WANT_EXPERIMENTAL before the #includes?

That seems drastic. We wouldn't get pretty much any use coverage of
any new code,
and that would just sweep the rug from under the whole idea of
feature-testing macros,
half of which is allowing bold users to adopt new facilities early.
Now they would need
to fall back to seventeen different implementation-specific ways to
opt in to that adoption,
which takes us back a decade. Please explain how your concerns about
atomic waits
are *anywhere near* the cost of doing that?