[PATCH 21/22] Define __HAVE_64B_ATOMICS from compiler support

[Stefan Liebler]

On 10/30/25 18:35, Wilco Dijkstra wrote:
> Hi Adhemerval,
>  
>> Now that atomic builtins are used by default, we can rely on the
>> compiler to define when to use 64-bit atomic operations.
>>
>> It allows the use of 64-bit atomic operations on some 32-bit ABIs where
>> they were not previously enabled due to missing pre-processor handling:
>> hppa, mips64n32, s390, and sparcv9.
>>
>> Co-authored-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
> 
> LGTM.
> 
> Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>
> 
> Cheers,
> Wilco
Hi,

I'm getting various testsuite FAILS with SIGILLs on s390 (31bit) since
this patch is committed.

__HAVE_64B_ATOMICS is now defined to 1 on s390 due to new
configure-check. Before it was set to 0 in s390-header-file.

As result, the cds-instruction is used via
atomic_compare_exchange_weak_acquire().
The SIGILL happens as the memory address is not 8byte-aligned.
The "data"-field of new_sem is used, which should really be
8byte-aligned on s390:
(gdb) ptype sem
type = struct new_sem {
    uint64_t data;
    int private;
    int pad;
} *
//<glibc>/sysdeps/nptl/internaltypes.h


BUT, e.g. sem_wait() gets an sem_t argument, which is only 4byte aligned
on s390. sem_t is then used as "struct new_sem"
(gdb) ptype sem_t
type = union {
    char __size[16];
    long __align; => only 4byte aligned on s390
}
//<glibc>/sysdeps/unix/sysv/linux/bits/semaphore.h

Some information about the datatypes on s390:
alignof(uint64_t)=8
alignof(long long)=8
alignof(struct new_sem)=8
alignof(long)=4
alignof(sem_t)=4

Some information about the cds-instruction and the SIGILL from the
z/Architecture Principles of Operation:
cds R1,R3,D2(B2)
... The
second operand of COMPARE AND SWAP (CSG)
and COMPARE DOUBLE AND SWAP (CDS, CDSY)
must be designated on a doubleword boundary. The
second operand of COMPARE DOUBLE AND SWAP
(CDSG) must be designated on a quadword bound-
ary. The R1 and R3 fields for COMPARE DOUBLE
AND SWAP must each designate an even-numbered
register. Otherwise, a specification exception is rec-
ognized.

Using long long as datatype for sem_t.__align solves the issues.
(e.g. aarch64 has it's own copy of
<glibc>/sysdeps/aarch64/nptl/bits/semaphore.h with also long long as
datatype)

But is this fixable at all, because bits/semaphore.h with the sem_t
datatype is an installed header-file. Thus there are already binaries
where a sem_t can be only at a 4byte-aligned memory location.

No idea if similar issues happen on hppa, mips64n32 or sparcv9.

Bye,
Stefan