Re: [GIT PULL] Add two-byte cmpxchg emulation function for v7.4

[David Laight <david.laight.linux@gmail.com>]

On Mon, 2 Nov 2026 13:21:04 +0100 (CET)
Jan Engelhardt <ej@inai.de> wrote:

> On Friday 2026-10-23 18:12, Paul E. McKenney wrote:
> >> >
> >> >Add emulation of two-byte cmpxchg()
> >> >
> >> >These commits add a cmpxchg_emu_u16() function that emulates two-byte
> >> >cmpxchg() in terms of four-byte cmpxchg() [...] 
> >> >namely sh, arc, csky, and xtensa.
> >> >
> >> >There is reason to believe that these systems will soon no longer be
> >> >supported by Linux.  
> >> 
> >> riscv64 also only has two exchange operations 
> >> (lr.w.aqrl/lr.d.aqrl/sc.w.rl/sc.d.rl). 
> >> (atomic_compare_exchange_strong with uint8/16_t, in userspace, gets 
> >> replaced by the compiler to a lot more instructions thanks to 
> >> implied -finline-atomics.)
> >> 
> >> Are you saying riscv64 is going to go unsupported too? ;-)  
> >
> >Given that the compiler can make it work in userspace, then the riscv64
> >architecture-specific code should be able to make it work in the Linux
> >kernel.  At which point there is absolutely no reason that Linux-kernel
> >support for riscv64 should be dropped.
> >
> >Or am I missing something here?  
> 
> I can get gcc-17.0.0-20261102 with no further command line options
> to turn `atomic_compare_exchange_strong`+uint16 into some object code
> that does not contain a call to libatomic, for sh2, sh3, sh4. Haven't 
> tried xtensa or the others.
> Thus, is the patch really needed?
> 

Won't that need a big jump in the minimum supported compiler version?
Probably less of a problem than x86 since I guess cross compiles are
a lot more common?

David