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.