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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Joerg Sonnenberger <joerg%bec.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, 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: Mon, 3 Apr 2023 08:10:31 +0000

 > Date: Thu, 30 Mar 2023 21:05:01 +0000 (UTC)
 > From: Joerg Sonnenberger <joerg%bec.de@localhost>
 > 
 > 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.
 
 These aren't hidden bugs.  They are spelled out in the C standard:
 
    When the processing of the abstract machine is interrupted by
    receipt of a signal, the values of objects that are neither
    lock-free atomic objects nor of type volatile sig_atomic_t are
    unspecified....  The value of any object modified by the handler
    that is neither a lock-free atomic nor of type volatile
    sig_atomic_t becomes indeterminate when the handler exits....
 
 > 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.
 
 Is this part of the contract of using C11 in NetBSD?  If so, we should
 really ship libatomic.