[PATCH 00/22] Cleanup internal atomic definitions

[Adhemerval Zanella Netto]

On 11/09/25 12:27, Uros Bizjak wrote:
> On Thu, Sep 11, 2025 at 3:52 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>> This patchset is based on previous work by Wilco [1] [2] to move all
>> targets' C11 atomics and remove the unused and redundant atomic
>> definitions.
>>
>> I took a more conservative approach and kept some arch-specific
>> definitions on some targets:
>>
>>   * alpha uses a ‘wmb’ for the atomic_write_barrier, and the instruction
>>     does not map to any C11 memory ordering.  Alpha has a peculiar
>>     semantic memory, so it's best to keep it.
>>
>>   * sparc also defines stronger definitions for all barriers.  I am not
>>     sure why a strong ordering was used, nor do I have a Sparc machine
>>     readily available to check if replacing it with a C11 barrier would
>>     be okay, so I will keep it.
>>
>>   * RISC-V defines optimized atomic_max and atomic_min, which are used in
>>     some statistical collection on malloc.  It also defines an
>>     atomic_spin_nop, used on pthread spinlocks and adaptive mutexes.
>>
>>   * x86 defines an atomic_spin_nop.
>>
>> [1] https://sourceware.org/pipermail/libc-alpha/2022-July/140817.html
>> [2] https://sourceware.org/pipermail/libc-alpha/2022-July/140817.html
>>
>> Adhemerval Zanella (20):
>>   aarch64: Remove ununsed atomic macros
> 
> Typo: *unused* here and below.
> 

Ack.

>>   arc: Remove ununsed atomic macros
>>   csky: Remove ununsed atomic macros
>>   mips: Remove ununsed atomic macros
>>   or1k: Remove ununsed atomic macros
>>   s390: Remove ununsed atomic macros
>>   sparc: Remove ununsed atomic macros
>>   x86: Remove ununsed atomic macros
>>   arm: Consolidade atomic-machine.h and Remove ununsed atomic macros
> 
> Typo: *Consolidate* here and below.
> 

Ack.

>>   hppa: Move atomic-machine to generic sysdep
>>   m68k: Consolidade atomic-machine.h and Remove ununsed atomic macros
>>   loongarch: Consolidate atomic-machine.h and remove ununsed atomic
>>     macros
>>   powerpc: Consolidate atomic-machine.h
>>   riscv: Consolidade atomic-machine.h and remove ununsed atomic macros
>>   sh: Move atomic-machine to generic sysdep
>>   alpha: Remove USE_ATOMIC_COMPILER_BUILTINS definition
>>   microblaze: Remove USE_ATOMIC_COMPILER_BUILTINS definition
>>   atomic: Consolidate atomic_full_barrier implementation
>>   atomic: Consolidate atomic_read_barrier implementation
>>   atomic: Consolidate atomic_write_barrier implementation
>>
>> Wilco Dijkstra (2):
>>   Define __HAVE_64B_ATOMICS from compiler support
>>   nptl: Remove ATOMIC_EXCHANGE_USES_CAS usage
> 
> Hello Adhemerval!
> 
> A patch, following removals of unused target atomic macros could
> remove #undefs from <include/atomic.h>:
> 
> # undef atomic_compare_and_exchange_val_acq
> # undef atomic_compare_and_exchange_val_rel
> # undef atomic_compare_and_exchange_bool_acq

Ack, will do.

> 
> Also, I wonder what is the purpose of:
> 
> # define atomic_forced_read(x) \
>   ({ __typeof (x) __x; __asm ("" : "=r" (__x) : "0" (x)); __x; })
> 
> This is *not* a scheduling barrier to prevent the compiler from
> reordering memory accesses (let alone the CPU), because it lacks
> "memory" clobber and/or volatile qualifier. To guarantee read to a
> register, this asm should use "memory" clobber, or it should be
> redefined to use atomic_load_acquire().

As Wilco's pointed out, this comes from an era where multiprocessor
was not the rule, and the C memory model was not well modeled. So we
have this subpar atomic code.