From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112144 invoked by alias); 23 Aug 2019 09:36:14 -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 112124 invoked by uid 89); 23 Aug 2019 09:36:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:4B203FA, H*f:sk:4B203FA, idsandoegooglemailcom, U*idsandoe X-HELO: mail-wr1-f50.google.com Received: from mail-wr1-f50.google.com (HELO mail-wr1-f50.google.com) (209.85.221.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Aug 2019 09:36:11 +0000 Received: by mail-wr1-f50.google.com with SMTP id r3so8021365wrt.3 for ; Fri, 23 Aug 2019 02:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GmRxjphce1K98wLDTntCa9a/fEDXqwxSQXhw4WPIePc=; b=cP8F9BL/E/DbLlXbWkDcbgAtPk8AhO1iK24n12nPVukm0TdSbMoTGnkLzeHc3YwIGe NoeQKGDvoJFomDSrqT7kGtHUPXe1GXy3rWrtPIVofUts8sLM+bhWhsQ8fyeVHvlA0Eay Tw43wqTeVop/6dG8M/cL5qMc73EUDqme9jNbetYc8fbz55F1XevV829XXcWFFWV68ZXd ZtrdDTmR1vS2VzvwHZrrWTPCYUwHFyiH/i/+4sF64i8Y5V+eZ1wK43ivz/iVg6SoKcpq wfukYbJMJyPQpv661cpbPdMCrwqEYCwb9eysrN1qoybKD23t7wrt9/+8AXeYfk+aBJ3O f8LQ== MIME-Version: 1.0 References: <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> In-Reply-To: <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> From: Jonathan Wakely Date: Fri, 23 Aug 2019 09:36:00 -0000 Message-ID: Subject: Re: gcc vs clang for non-power-2 atomic structures To: Iain Sandoe Cc: Jim Wilson , GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00194.txt.bz2 On Fri, 23 Aug 2019 at 08:21, Iain Sandoe wrote: > > Hi Jim, > > > On 23 Aug 2019, at 00:56, Jim Wilson wrote: > > > > We got a change request for the RISC-V psABI to define the atomic > > structure size and alignment. And looking at this, it turned out that > > gcc and clang are implementing this differently. Consider this > > testcase > > > > rohan:2274$ cat tmp.c > > #include > > struct s { int a; int b; int c;}; > > int > > main(void) > > { > > printf("size=3D%ld align=3D%ld\n", sizeof (struct s), _Alignof(struct = s)); > > printf("size=3D%ld align=3D%ld\n", sizeof (_Atomic (struct s)), > > _Alignof(_Atomic (struct s))); > > return 0; > > } > > rohan:2275$ gcc tmp.c > > rohan:2276$ ./a.out > > size=3D12 align=3D4 > > size=3D12 align=3D4 > > rohan:2277$ clang tmp.c > > rohan:2278$ ./a.out > > size=3D12 align=3D4 > > size=3D16 align=3D16 > > rohan:2279$ > > > > This is with an x86 compiler. > > A search for _Atomic in the latest (x86_64) psABI document shows no resul= ts. See https://groups.google.com/forum/#!topic/ia32-abi/Tlu6Hs-ohPY and the various GCC bugs linked to from that thread. This is a big can of worms, and GCC needs fixing (but probably not until the ABI group decide something). > > I get the same result with a RISC-V > > compiler. This is an ABI incompatibility between gcc and clang. gcc > > has code in build_qualified_type in tree.c that sets alignment for > > power-of-2 structs to the same size integer alignment, but we don't > > change alignment for non-power-of-2 structs. Clang is padding the > > size of non-power-of-2 structs to the next power-of-2 and giving them > > that alignment. > > If the psABI makes no statement about what _Atomic should do, AFAIK > the compiler is free to do something different (for the same entity) from > the non-_Atomic version. Right, but GCC and Clang should agree. So it needs to be in the psABI. > e.g from 6.2.5 of n2176 (C18 draft) > > =E2=80=A2 27 Further, there is the _Atomic qualifier. The presen= ce of the _Atomic qualifier designates an atomic type. The size, representa= tion, and alignment of an atomic type need not be the same as those of the = corresponding unqualified type. Therefore, this Standard explicitly uses th= e phrase =E2=80=9Catomic, qualified or unqualified type=E2=80=9D whenever t= he atomic version of a type is permitted along with the other qualified ver= sions of a type. The phrase =E2=80=9Cqualified or unqualified type=E2=80=9D= , without specific mention of atomic, does not include the atomic types. > > So the hole (in both cases) to be plugged is to add specification for _At= omic > variants to the psABI=E2=80=A6. > > =E2=80=A6 of course, it makes sense for the psABI maintainers to discuss = with > the compiler =E2=80=9Cvendors=E2=80=9D what makes the best choice. > > (and it=E2=80=99s probably a significant piece of work to figure out all = the interactions > with __attribute__ modifiers) > > > Unfortunately, I don't know who to contact on the clang side, but we > > need to have a discussion here, and we probably need to fix one of the > > compilers to match the other one, as we should not have ABI > > incompatibilities like this between gcc and clang. > > The equivalent of =E2=80=9CMAINTAINERS=E2=80=9D in the LLVM sources for b= ackends is > =E2=80=9Cllvm/CODE_OWNERS.TXT=E2=80=9D which says that Alex Bradbury is t= he code > owner for the RISC-V backend. Tim Northover and JF Bastien at Apple should probably be involved too. IMO GCC is broken, and the longer we take to fix it the more painful it will be for users as there will be more code affected by the change.