On Thursday, January 1, 2026, Simon Schröder wrote:

>
>
> You seem to forget that you are linking against the C and C++ standard
> libraries.These have to be compiled either with backwards compatibility or
> with cmpxchg16b. Also, there are parts of them which are typically dynamic
> libraries. Are you suggesting that Linux distributions should ship two
> libraries and do some magic to select the right one? I think it is quite
> obvious why Linux distributions choose backwards compatibility.
>



Backwards-compatibility is a noble goal . . . I mean it was vital that the
Playstation 2 could play all the Playstation 1 games, and it's handy that
you can put a Mach 3 Turbo razor into a Mach 3 handle.

But there comes a point when the backwards-compatibility just isn't worth
it. I've been trying to dig up info and here's what I found:

    Intel: All Intel x86_64 CPUs include CMPXCHG16B

    AMD: The holdouts were early K8 parts before Revision F. Those pre-F
(2006 and earlier) chips lacked CMPXCHG16B.

So we're talking about computers from about 17 or 18 years ago. That's a
long time. That's like making sure the Playstation 5 can still play
Playstation 2 games. I'll admit it would be cool to be able to play PS2
games on a PS5, but not at any substantial cost.

I'm on holidays right now but when I get home next week I'm patching the
GNU compiler so that CMPXCHG16B will be placed inline.

And worst case scenario if you run one of my programs on an AMD computer
from 2006, you'll just see:

    SIGILL: Illegal Instruction

So it will be a hard failure rather than an intermittent bug. Plus, just to
be safe, I'll edit the libatomic function so that it calls 'abort' -- just
in case there's a translation unit or shared library somewhere that tries
to use it.