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?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.