On Thu, 1 Jan 2026, 15:55 Jonathan Wakely, <cxx_at_[hidden]> wrote:

>
>
> On Thu, 1 Jan 2026, 13:37 Frederick Virchanza Gotham via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> 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
>>
>
> Nocona doesn't, as far as I know
>

Nor some low-power processors like early Atom models, and apparently modern
ones including Novalake which is due to launch later in 2026.



>
>> 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.
>>
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>