Re: port-sh3/60773: sh3 __sync_val_compare_and_swap_1 test failures

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR toolchain/60773; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Valery Ushakov <uwe%stderr.spb.ru@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
	Nick Hudson <skrll%NetBSD.org@localhost>
Subject: Re: port-sh3/60773: sh3 __sync_val_compare_and_swap_1 test failures
Date: Thu, 24 Sep 2026 12:37:51 +0000

 > Date: Thu, 24 Sep 2026 15:14:33 +0300
 > From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
 >=20
 > Tangential to the topic at hand, but since I had to read the code, I
 > might as well ask - why is atomic_init_testset.c statically
 > initializes the _fn variables to _up functions only immediately to set
 > them to _mp functions in __libc_atomic_init (and later set them back
 > to _up if we are on a UP system and rasctl(2) was successful)?  Any
 > reason not to init the vars to _mp directly?  _mp functions use the
 > locks array that is statically initialized, so it should be safe to
 > call them before __libc_atomic_init, shouldn't it?
 
 The code was originally added with no initializer by ad@ in 2008,
 under the assumption the constructor would always run before use, and
 the constructor started with the always-safe _mp variants before
 deciding on the basis of sysctl whether to use the cheaper _up
 variants if safe:
 
 https://mail-index.netbsd.org/source-changes/2008/02/09/msg002110.html
 https://nxr.netbsd.org/xref/src/common/lib/libc/atomic/atomic_init_testset.=
 c?r=3D1.1#63
 
 skrll@ added the initializer because the constructor didn't always run
 before use, but it's unclear why he chose _up:
 
 https://mail-index.netbsd.org/source-changes/2009/01/30/msg216500.html
 https://nxr.netbsd.org/xref/src/common/lib/libc/atomic/atomic_init_testset.=
 c?r=3D1.6#63
 
 This actually caused some trouble for us later on with the _up
 variants getting inadvertently used in ld.elf_so until martin@ changed
 it to call __libc_atomic_init in 2023:
 
 PR lib/57628: multithread programs may deadlock in ld.elf_so (sparc on
 sparc64)
 https://gnats.NetBSD.org/57628
 https://mail-index.netbsd.org/source-changes/2023/10/03/msg147830.html
 https://nxr.netbsd.org/xref/src/libexec/ld.elf_so/rtld.c?r=3D1.216#72
 
 > If there's a reason why it's done in this way, it probably warrants a
 > comment.
 
 I think the reason is `hysterical raisins' and this warrants a commit
 to make the static initializers use _mp and then delete the
 now-redundant initial assignments in __libc_atomic_init.