As [1] says, we cannot mix up lock-free and locking atomics for one
object.  For example assume atom = (0, 0) initially, if we have a
locking "atomic" xor running on T0 and a lock-free store running on T1
concurrently:

       T0                    |       T1
-----------------------------+-------------------------------------
 acquire_lock                |
 t0 = atom[0]                |
 /* some CPU cycles */       | atom = (1, 1) /* lock-free atomic */
 t1 = atom[1]                |
 t0 ^= 1                     |
 t1 ^= 1                     |
 atom[0] = t0                |
 atom[1] = t1                |
 release_lock                |

we get atom = (0, 1), but the atomicity of xor and store should
guarantee that atom is either (0, 0) or (1, 1).

So, if we want to use a lock-free 16B atomic operation, we need both LSX
and SCQ even if that specific operation only needs one of them.  To make
things worse, one may link a TU compiled with -mlsx -mscq and another
without them together, then if we want to use the lock-free 16B atomic
operations in the former, we must make libatomic also use the lock-free
16B atomic operation for the latter so we need to add ifuncs for
libatomic, similar to the discussion about i386 vs. i486 in [1].

Implementing and building the ifuncs currently requires:

- Glibc, because the ifunc resolver interface is libc-specific
- Linux, because the HWCAP bit for LSX is kernel-specific
- A recent enough assembler at build time to recognize sc.q

So the approach here is: only allow 16B lock-free atomic operations in
the compiler if the criteria above is satisfied, and ensure libatomic to
use those lock-free operations on capable hardware (via ifunc unless
both LSX and SCQ are already enabled by the builder) if the compiler
allows 16B lock-free atomic.

[1]: https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary

gcc/
	* configure.ac (HAVE_AS_16B_ATOMIC): Define if the assembler
	supports LSX and sc.q.
	* configure: Regenerate.
	* config.in: Regenerate.
	* config/loongarch/loongarch-opts.h (HAVE_AS_16B_ATOMIC):
	Defined to 0 if undefined yet.
	* config/loongarch/linux.h (HAVE_IFUNC_FOR_LIBATOMIC_16B):
	Define as HAVE_AS_16B_ATOMIC && OPTION_GLIBC.
	* config/loongarch/loongarch-protos.h
	(loongarch_16b_atomic_lock_free_p): New prototype.
	* config/loongarch/loongarch.cc
	(loongarch_16b_atomic_lock_free_p): Implement.
	* config/loongarch/sync.md (atomic_storeti_lsx): Require
	loongarch_16b_atomic_lock_free_p.
	(atomic_storeti): Likewise.
	(atomic_exchangeti_scq): Likewise.
	(atomic_exchangeti): Likewise.
	(atomic_compare_and_swapti): Likewise.
	(atomic_fetch_<amop_ti_fetch>ti_scq): Likewise.
	(atomic_fetch_<amop_ti_fetch>ti): Likewise.
	(ALL_SC): Likewise for TImode.
	(atomic_storeti_scq): Remove.

libatomic/

	* configure.ac (ARCH_LOONGARCH): New AM_CONDITIONAL.
	* Makefile.am (IFUNC_OPT): Separate the item from IFUNC_OPTIONS
	to allow using multiple options for an ISA variant.
	(libatomic_la_LIBADD): Add *_16_1_.lo for LoongArch.
	(IFUNC_OPTIONS): Build *_16_1_.lo for LoongArch with -mlsx and
	-mscq.
	* configure: Regenerate.
	* Makefile.in: Regenerate.
	* configure.tgt (try_ifunc): Set to yes for LoongArch if the
	compiler can produce lock-free 16B atomic with -mlsx -mscq.
	* config/loongarch/host-config.h: Implement ifunc selector.

This optional header is used to bring in the definition of the
struct __ifunc_arg_t type. Since it has been added to glibc only
recently, the previous implementation had to check whether this
header is present and, if not, it provide its own definition.

This creates dead code because either one of these two parts would
not be tested. The ABI specification for ifunc resolvers allows to
create own ABI-compatible definition for this type, which is the
right way of doing it.

In addition to improving consistency, the new approach also helps
with addition of new fields to struct __ifunc_arg_t type without
the need to work-around situations when the definition imported
from the header lacks these new fields.

ABI allows to define as many hwcap fields in this struct as needed,
provided that at runtime we only access the fields that are permitted
by the _size value.

gcc/
	* config/aarch64/aarch64.cc (build_ifunc_arg_type):
	Add new fields _hwcap3 and _hwcap4.

libatomic/
	* config/linux/aarch64/host-config.h (__ifunc_arg_t):
	Remove sys/ifunc.h and add new fields _hwcap3 and _hwcap4.

libgcc/
	* config/aarch64/cpuinfo.c (__ifunc_arg_t): Likewise.
	(__init_cpu_features): obtain and assign values for the
	fields _hwcap3 and _hwcap4.
	(__init_cpu_features_constructor): check _size in the
	arg argument.

Here is just a port of the previously posted patch to mingw which
clearly has the same problems.

2025-04-16  Jakub Jelinek  <jakub@redhat.com>

	PR libgcc/101075
	PR libgcc/119796
	* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
	computing how many locks will be needed and take into account
	((uintptr_t)ptr % WATCH_SIZE).  If some locks from the end of the
	locks array and others from the start of it will be needed, first
	lock the ones from the start followed by ones from the end.

As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
   acquired always in the order from addr_hash (ptr) up to
   locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
   so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
   case at pointer starting at page boundary and in another case at
   page boundary + 2048 bytes, the first thread can lock the first
   32 mutexes, the second thread can lock the last 32 mutexes and
   then first thread wait for the lock 32 held by second thread and
   second thread wait for the lock 0 held by the first thread;
   fixed below by always locking the locks in order of increasing
   index, if there is a wrap-around, by locking in 2 loops, first
   locking some locks at the start of the array and second at the
   end of it
2) the number of locks seems to be determined solely depending on the
   n value, I think that is wrong, we don't know the structure alignment
   on the libatomic side, it could very well be 1 byte aligned struct,
   and so how many cachelines are actually (partly or fully) occupied
   by the atomic access depends not just on the size, but also on
   ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
   should IMHO lock 2 locks because it occupies the first and second
   cacheline

Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.

2025-04-16  Jakub Jelinek  <jakub@redhat.com>

	PR libgcc/101075
	PR libgcc/119796
	* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
	computing how many locks will be needed and take into account
	((uintptr_t)ptr % WATCH_SIZE).  If some locks from the end of the
	locks array and others from the start of it will be needed, first
	lock the ones from the start followed by ones from the end.

Simplify and cleanup ifunc selection logic.  Since LRCPC3 does
not imply LSE2, has_rcpc3() should also check LSE2 is enabled.

Passes regress and bootstrap, OK for commit?

libatomic:
	* config/linux/aarch64/host-config.h (has_lse2): Cleanup.
	(has_lse128): Likewise.
	(has_rcpc3): Add early check for LSE2.

libatomic/ChangeLog:

	* config/linux/aarch64/atomic_16.S (FEATURE_1_GCS): Define.
	(GCS_FLAG): Define if GCS is enabled.
	(GNU_PROPERTY): Add GCS_FLAG.

	PR target/104688

libatomic/ChangeLog:

	* config/x86/init.c (__libat_feat1_init): Don't clear
	bit_AVX on ZHAOXIN CPUs.

Check the result of __get_cpuid and process FEAT1_REGISTER only when
__get_cpuid returns success.  Use __cpuid instead of nested __get_cpuid.

libatomic/ChangeLog:

	* config/x86/init.c (__libat_feat1_init): Check the result of
	__get_cpuid and process FEAT1_REGISTER only when __get_cpuid
	returns success.  Use __cpuid instead of nested __get_cpuid.

The introduction of the optional RCPC3 architectural extension for
Armv8.2-A upwards provides additional support for the release
consistency model, introducing the Load-Acquire RCpc Pair Ordered, and
Store-Release Pair Ordered operations in the form of LDIAPP and STILP.

These operations are single-copy atomic on cores which also implement
LSE2 and, as such, support for these operations is added to Libatomic
and employed accordingly when the LSE2 and RCPC3 features are detected
in a given core at runtime.

libatomic/ChangeLog:

	* config/linux/aarch64/atomic_16.S (libat_load_16): Add LRCPC3
	variant.
	(libat_store_16): Likewise.
	* config/linux/aarch64/host-config.h (HWCAP2_LRCPC3): New.
	(LSE2_LRCPC3_ATOP): Previously LSE2_ATOP.  New ifuncs guarded
	under it.
	(has_rcpc3): New.