Date: Thu, 1 Jan 2026 09:38:37 +0100
> On Dec 31, 2025, at 3:26 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I do see the rationale here, I can see why the GNU decision makers decided to do this -- the logic is not lost on me -- but I also think it means that x86-64-v2 users suffer an unnecessary performance penalty (i.e. jumping into a function that contains a 'cmpxchg16b' instruction instead of just placing the instruction inline).
>
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.
Also, we are talking about atomics. Are you sure their overhead is less than a function call?
>
> I do see the rationale here, I can see why the GNU decision makers decided to do this -- the logic is not lost on me -- but I also think it means that x86-64-v2 users suffer an unnecessary performance penalty (i.e. jumping into a function that contains a 'cmpxchg16b' instruction instead of just placing the instruction inline).
>
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.
Also, we are talking about atomics. Are you sure their overhead is less than a function call?
Received on 2026-01-01 08:38:51