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. I realise that's okay for a lot of people, but not for me.
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. 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.


> 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.

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.