On Friday, 9 January 2026 20:27:10 Brasilia Standard Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> > The fact that some implementations have a wrong answer is a QoI problem.
>
> Not necessarily a QoI problem. You could call it a QoS problem. When
> the committee decided that 'is_always_lock_free' can give a different
> answer to 'is_lock_free', they opened the door to all manner of
> trickery . . . . . . . such as jumping into libatomic instead of
> placing cx16 in place. It should never have happened.

That's just wrong.

First of all, the two things are not connected to each other.

The fact that the compilers do or don't inline content is irrelevant. They
could emit inline code for both implementations if they wanted. They chose not
to. And Jonathan has already posted that he's willing to fix GCC to inline the
CX16/AVX instructions if those are enabled at compile-time.

So please stop talking about libatomic and the lack of inlining. That's not
nor has that ever been a problem.

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.

If you want an ABI-incompatible flag to have the compilers change the answer,
you're welcome to suggest that. But I doubt the vendors will accept simply on
the CPU target architecture flags, because changing is_always_lock_free is an
ABI change and may cause ODR problems. Suppose you have some code that checks
that and makes different choices on how to implement some algorithm: if the
variable changes, then so will the choice be, and could result in silent data
incompatibilities.

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