[PATCH v2] Revert __HAVE_64B_ATOMICS configure check

[Adhemerval Zanella Netto]

On 14/11/25 00:15, H.J. Lu wrote:
> On Fri, Nov 14, 2025 at 6:54 AM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>>
>> Hi HJ,
>>
>>>>> This is wrong for x32 which has 64-bit atomic and __WORDSIZE == 32.
>>>>
>>>> Why would it be wrong? If 'long' is 4-byte aligned, it has the same issue
>>>
>>> Did you mean "long long"?  On x32, long is 4-byte.
>>
>> No, it's about the alignment of 'long'.
>>
>>>> as 32-bit x86. You need full support for unaligned 64-bit atomics before
>>>> you can turn it on.
>>>
>>> The only difference between x32 and x86-64 is the size of long.  If
>>> x86-64 supports 64-bit atomics, so does x32.
>>
>> The code does 64-bit atomics with alignment of a 'long'. On 64-bit
>> targets all is well, but if 'long' is 4-byte aligned, it will fail. So we cannot
>> use 64-bit atomics on 32-bit targets.
>>
> 
> This doesn't make any senses:
> 
> #if __HAVE_64B_ATOMICS == 1
> 
> static inline uint64_t
> __condvar_fetch_xor_wseq_release (pthread_cond_t *cond, unsigned int val)
> {
>   return atomic_fetch_xor_release (&cond->__data.__wseq.__value64, val);
> }
> 
> #else /* !__HAVE_64B_ATOMICS */
> 
> I didn't see "long" here.   x32 supports atomic uint64_t operations, just like
> x86-64.
> 

I think it my better to rename __HAVE_64B_ATOMICS to USE_64B_ATOMICS, and it
seems that prior this change x32 does define it (even though sem_t uses
long int as alignment anchor and it has a value of 4).

For mips64 glibc used to define:

#if _MIPS_SIM == _ABIO32 || _MIPS_SIM == _ABIN32
#define __HAVE_64B_ATOMICS 0
#else
#define __HAVE_64B_ATOMICS 1
#endif

I think it would be best to just revert to the old usage of the atomics and
then we can evaluate ABI per ABI if we can switch to 64-bit atomics.

I will fix the x32 definition and change the macro name to something more
meaningful.