From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54006 invoked by alias); 23 Aug 2019 10:13:04 -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 53997 invoked by uid 89); 23 Aug 2019 10:13:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=idsandoe@googlemail.com, idsandoegooglemailcom, H*f:sk:CAH6eHd, H*i:sk:CAH6eHd X-HELO: mail-wr1-f53.google.com Received: from mail-wr1-f53.google.com (HELO mail-wr1-f53.google.com) (209.85.221.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Aug 2019 10:13:01 +0000 Received: by mail-wr1-f53.google.com with SMTP id k2so8127680wrq.2 for ; Fri, 23 Aug 2019 03:13:01 -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=s+mIdDpTc5yducCtHij74W4CUJBtan68PharnSGpuYg=; b=ap8mUDii9OpZKX/LhUv5sOAfb+Q7OT8Ck1SQXc5knatDjA3dBVrJrHc9IzoXUV7BH0 TH3ECH7KoSjswyAL2fNl5mBpwCDmy/SBckXTFAgwYXk64ERS7yargoYo7C75PkHpk1GX aAAo9oVzHi78p/aZZwQ3G2XY43SV+lFsSGVb7Gg7doUmG/MxgiqVUSb2KaZjLy1HgJZe l24nkMy7s3fKC8WW8av5g6KtZrzV7NcUn/hVKJKb4nQpY/O6IQ3xfQnPPEV1i3y0Xp+7 51eijd62J0+CMnoqkJWWND9gEdi2wXhYGevSs+rM6SZXytDFTH4Lk/Q3k+OqEj1LFJgi Mrlw== 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 w8sm12532347wmc.1.2019.08.23.03.12.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 03:12:59 -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 10:13:00 -0000 Cc: Jim Wilson , GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <1B1B7543-E830-43C6-B996-7FE51E4540E1@googlemail.com> References: <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> To: Jonathan Wakely X-SW-Source: 2019-08/txt/msg00195.txt.bz2 > On 23 Aug 2019, at 10:35, Jonathan Wakely wrote: >=20 > On Fri, 23 Aug 2019 at 08:21, Iain Sandoe wrote: >>=20 >> Hi Jim, >>=20 >>> On 23 Aug 2019, at 00:56, Jim Wilson wrote: >>>=20 >>> 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 >>>=20 >>> 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$ >>>=20 >>> This is with an x86 compiler. >>=20 >> A search for _Atomic in the latest (x86_64) psABI document shows no resu= lts. >=20 > See https://groups.google.com/forum/#!topic/ia32-abi/Tlu6Hs-ohPY and > the various GCC bugs linked to from that thread. >=20 > This is a big can of worms, and GCC needs fixing (but probably not > until the ABI group decide something). I agree about the size of the can of worms. However, there doesn=E2=80=99t seem to be any actual issue filed on: https://github.com/hjl-tools/x86-psABI Would it help if someone did? >>> 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. >>=20 >> 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. >=20 > Right, but GCC and Clang should agree. So it needs to be in the psABI. absolutely, it=E2=80=99s the psABI that=E2=80=99s lacking here - the compil= ers (as commented by Richard Smith in a referenced thread) should not be making ABI up=E2=80= =A6 >> e.g from 6.2.5 of n2176 (C18 draft) >>=20 >> =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. >>=20 >> So the hole (in both cases) to be plugged is to add specification for _A= tomic >> variants to the psABI=E2=80=A6. >>=20 >> =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. >>=20 >> (and it=E2=80=99s probably a significant piece of work to figure out all= the interactions >> with __attribute__ modifiers) >>=20 >>> 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. >>=20 >> The equivalent of =E2=80=9CMAINTAINERS=E2=80=9D in the LLVM sources for = backends is >> =E2=80=9Cllvm/CODE_OWNERS.TXT=E2=80=9D which says that Alex Bradbury is = the code >> owner for the RISC-V backend. >=20 > Tim Northover and JF Bastien at Apple should probably be involved too. >=20 > 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. I suspect that (even if this is not a solution chosen elsewhere), for Darwi= n, there will have to be a target hook to control this since I can=E2=80=99t c= hange the ABI retrospectively for the systems already released. That is, GCC is emit= ting broken code on those platforms anyway (since the platform ABI is determined by what clang/llvm produces). Iain