sob., 10 sty 2026 o 15:39 Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Friday, 9 January 2026 22:46:26 Brasilia Standard Time Frederick Virchanza
> Gotham via Std-Proposals wrote:
> > On Sat, Jan 10, 2026 at 1:05 AM Thiago Macieira wrote:
> > > So please stop talking about libatomic and the lack of inlining. That's
> > > not
> > > nor has that ever been a problem.
> >
> > It's a problem right now for extreme optimisers trying to pinch every
> > last nanosecond. If you use __atomic_fetch_add_16 in your C++ program
> > compiled with GNU g++ and check the assembler, you'll see a function
> > call.
>
> That's QoI, not a standard problem. And Jonathan has already said he's working
> on fixing it.
>
> > Plus I can see a few bug reports online where some programs have been
> > linked improperly and so you've got some parts of the program using a
> > mutex and other parts using cx16.
>
> That's a bug. That's also why is_always_lock_free can't change.
>
> > This scenario should never have
> > become a possibility because std::atomic should never have been
> > allowed to use a mutex. I think std::atomic using a lock is awful --
> > and I actually couldn't believe that these locks are located in a
> > global map indexed by memory address. Ugh.
>
> You're talking from the 2026 point of view. Now put yourself back in 2005 when
> these discussions were happening. QAtomicInteger & QBasicAtomicInteger, which
> predate std::atomic by 6 years, never offered support for non-integer and non-
> pointer types and still doesn't, but we still had to have locked solutions,
> because in 2005 not all platforms had atomics in hardware. Two that come to
> mind are HP's PA-RISC and ARMv5 cores. For the latter, we depended on kernel
> support to disable interrupts, perform the operation, then re-enable them -
> not exactly a lock, but effectively the same thing.
>
> The ability to perform some atomic operations in cross-platform code in spite
> of there being no underlying hardware support was useful. Still is, though the
> occurrence rate for regular-sized integer is near zero now.
>
> > > As for whether is_always_lock_free can be different from is_lock_free(),
> > > that's just semantics, very clear from the name. If an atomic isn't
> > > always lock free, then it may still be *sometimes* lock free. And on
> > > x86-64, 128-bit atomics aren't always lock free in the ABI. No amount of
> > > arguing in this mailing list or in the compilers will change that.
> >
> > I would want to have two different builds: One for modern x86_64
> > CPU's, and one for 17-year-old x86_64 CPU's just in case someone's
> > laptop gets left on a train and they need to climb up into the attic
> > to get the old desktop PC down.
>
> Ok, go ahead.
>
> Please point to me *any* consumer-available full software distribution of any
> OS that *requires* AVX2. There isn't one. Software still runs on non-AVX2
> hardware. Therefore, software still retains the ability to run on hardware
> without 128-bit atomics.
>
> So if you're willing to rebuild the world, you can always do so, with your own
> ABI-incompatible changes that suit your fancy.
>
> That does not affect the Standard. And that's my point: you're barking up the
> wrong tree. There's nothing wrong with the Standard.
>
> > I don't want the new computers to be burdened by the old computers,
> > however I am okay about accommodating the older computers with
> > separate binaries.
>
> Sure.
>
> And a /lib64/glibc-hwcaps/x86-64-v3/libatomic.so.1 could remove the IFUNC and
> go straight to the implementations using CX16. It's probably not worth it.
>
> Your x86-64-v3/libwhatever.so can inline the AVX2 and CX16 instructions, once
> Jonathan fixes GCC. It's ABI-compatible with older software not compiled as
> such, calling into libatomic.
>
> So why are you still complaining?

The most insane thing is that at some point the whole problem could be solved by
small function with assembly and not bothering anyone else.
And even more funny is that he need this now when any std change will
take years to be available to end users.

>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals