Re: lib/57312: Missing atomic symbols generated by gcc

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/57312: Missing atomic symbols generated by gcc
Date: Thu, 30 Mar 2023 23:00:30 +0200

 Am Thu, Mar 30, 2023 at 03:20:00PM +0000 schrieb campbell+netbsd%mumble.net@localhost:
 > libc is missing many of the __atomic_* symbols that gcc generates references to for certain out-of-line cases of the C11 stdatomic.h API.
 > 
 > Cases where symbols are missing:
 > 
 > - On architectures that don't natively have CAS, like sparc, hppa, and early mips.
 > - For objects of unnaturally large sizes, for which atomic_is_lock_free is false and locking is required.
 > - When the -fno-inline-atomics flag is passed.
 > 
 > We probably need to define all the symbols listed here:
 > https://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c
 
 > 
 > I added __atomic_is_lock_free for a handful of architectures where its absence immediately broke the OpenSSL build, but there are lots more.
 
 I strongly object to adding implementations that have hidden bugs when
 used with shared memory, signals and other situations. I'd go a step
 further and would ask to de-orbit SPARCv8 SMP just for that alone. HPPA
 etc doesn't matter as RAS is fine for shared memory.
 
 I'd also note that the whole atomic API is majorly broken for the
 non-lockfree case, but I guess no one else cares enough about the hidden
 bugs... For those that doesn't care, they can use -latomic.
 
 Joerg