From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6601 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1 Date: Sun, 23 Nov 2014 10:21:29 -0500 Message-ID: <20141123152129.GJ29621@brightrain.aerifal.cx> References: <386bdfe0.dNq.dMV.22.ce88IE@mailjet.com> <1415553117.2457.1250.camel@eris.loria.fr> <28e7e26d.dNq.dMV.24.cxrFKH@mailjet.com> <1416697795.16006.338.camel@eris.loria.fr> <20141122233022.GE29621@brightrain.aerifal.cx> <1416706295.16006.354.camel@eris.loria.fr> <20141123014354.GF29621@brightrain.aerifal.cx> <1416735814.16006.387.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416756110 4116 80.91.229.3 (23 Nov 2014 15:21:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2014 15:21:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6614-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 23 16:21:44 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XsYyt-0006VF-GE for gllmg-musl@m.gmane.org; Sun, 23 Nov 2014 16:21:43 +0100 Original-Received: (qmail 11837 invoked by uid 550); 23 Nov 2014 15:21:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11826 invoked from network); 23 Nov 2014 15:21:41 -0000 Content-Disposition: inline In-Reply-To: <1416735814.16006.387.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6601 Archived-At: On Sun, Nov 23, 2014 at 10:43:34AM +0100, Jens Gustedt wrote: > Hello, > > Am Sonntag, den 23.11.2014, 02:47 +0100 schrieb Joakim Sindholt: > > GCC 4.9: > > > > typedef _Atomic struct > > { > > #if __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1 > > _Bool __val; > > #else > > unsigned char __val; > > #endif > > } atomic_flag; > > > > Clang 3.6: > > > > #ifdef __cplusplus > > typedef _Atomic(bool) atomic_bool; > > #else > > typedef _Atomic(_Bool) atomic_bool; > > #endif > > > > typedef struct atomic_flag { atomic_bool _Value; } atomic_flag; > > So they fucked it up and have incompatible declarations? Great. The differences are minor, and are things that are generally considered non-issues when linking code from two different compilers/implementations of the language which share an ABI. The only differences are the name of the member (__val vs _Value) and whether its type is atomic-qualified. I agree there's room for different interpretations, but my view is that when you're linking code produced by different compilers that have agreed on an ABI, matching the size/representation/layout is generally sufficient. > For the discussion about the second case for the type, this is the > question if there are archs that implement TAS operations with other > values than 0 for "unset" and 1 for "set". There seem to be archs out > there that implement TAS with other values, I vaguely remember having > heard about some risk arch (??). Actually this also is the reason why > the standard defines this type in such a weird manner, and why per the > standard it needs a dedicated initialization macro, default > initialization with 0 doesn't do in all cases. These are not archs we can support with musl, so they wouldn't be relevant. And they're not archs that could support POSIX without a kernel stop-the-world approach for implementing CAS, or syscalls for every synchronization action. Rich