From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2282 invoked by alias); 23 Aug 2019 18:59:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2272 invoked by uid 89); 23 Aug 2019 18:59:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=sponsor X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Aug 2019 18:59:54 +0000 Received: by mail-wr1-f68.google.com with SMTP id t16so9533499wra.6 for ; Fri, 23 Aug 2019 11:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7EiYJB3iGIjop7ijPy/luHmHdzs+5YWgFOl3L/ueaAs=; b=Qox5CUa5FHCQN0PDBzQhSzqPalyOuatlOk90P3xB3jyKe8HHUEcXit4zrr8ICyIAgT AAUjFE+7qbHtCak5f9k1/6T90U4AnLh4GUOIKQbKLqUf2wouzNSqbfWGcoAGWjWqZ35k eAjMaEwp/zyT+uL4BFEPIET7J0fXV+5xWnVeytA7gHpzyyrMGK5FzCf6qfi9kyBGspEp Q1IjwEoJOwUUCyG3SbGuBty7zzrF36IMAN8WAZR5P3F5oFdBXsFGlNESkoquSL25ZIAo etirSFXGxe38ky6F0QDJdwC34pTzSb0+xyCcDPDW7Y1OS5/Az6cEEVOXswM0i0cGblTI d/7A== Return-Path: Received: from euterpe-sie.home (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id w5sm4224002wmm.43.2019.08.23.11.59.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 11:59:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: gcc vs clang for non-power-2 atomic structures From: Iain Sandoe In-Reply-To: Date: Fri, 23 Aug 2019 18:59:00 -0000 Cc: Jonathan Wakely , Jim Wilson , GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> <1B1B7543-E830-43C6-B996-7FE51E4540E1@googlemail.com> To: Joseph Myers X-SW-Source: 2019-08/txt/msg00203.txt.bz2 Hi Joseph, > On 23 Aug 2019, at 17:14, Joseph Myers wrote: >=20 > On Fri, 23 Aug 2019, Iain Sandoe wrote: >=20 >> absolutely, it=E2=80=99s the psABI that=E2=80=99s lacking here - the com= pilers (as commented >> by Richard Smith in a referenced thread) should not be making ABI up=E2= =80=A6 >=20 > With over 50 target architectures supported in GCC, most of which probabl= y=20 > don't have anyone maintaining a psABI for them, you don't get support for= =20 > new language features that require an ABI without making some reasonable= =20 > default choice that allows the features to work everywhere and then=20 > letting architecture maintainers liaise with ABI maintainers in the case= =20 > where such exist. yes. That=E2=80=99s perfectly reasonable However, it=E2=80=99s more than a little disappointing that X86, for which = I would hope that the psABI _was_ considered supported, remains silent on the issue so l= ong after it arose (I guess the interested parties with $ need to sponsor some = work to update it). > (ABIs for atomics have the further tricky issue that there can be multipl= e=20 > choices for how to map the memory model onto a given architecture; see=20 > . So it's not=20 > just a matter of type sizes and alignment.) Indeed, I have tangled a bit with that trying to adapt libatomic to be bett= er behaved on Darwin. > but where psABIs=20 > specify something we do of course need to follow it (and the choice may b= e=20 > OS-specific, not just processor-specific, where the ABI is defined by the= =20 > default compiler for some OS). agreed .. it seems highly likely for X86 as things stand - since there=E2= =80=99s a bunch of things already out there with different ABIs baked in. >=20 > Note: it's likely some front-end code, and stdatomic.h, might have to=20 > change to handle the possibility of atomic types being larger than=20 > non-atomic, as those end up using type-generic atomic load / store=20 > built-in functions, and those certainly expect pointers to arguments of=20 > the same size (when one argument is the atomic type and one non-atomic). It seems to me that whatever might be chosen for the definitive psABI / pla= tform (i.e. arch + OS + version) going forward, we will need to support what has been emitted in the past. So a recommendation for suitable FE hooks (and preferably a way to make the C11 atomic match the std::atomic, even if this is =E2=80=9Conly=E2=80= =9D a QoI issue), would be worth addressing. thanks Iain >=20 > --=20 > Joseph S. Myers > joseph@codesourcery.com