From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89964 invoked by alias); 23 Aug 2019 07:21:25 -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 89956 invoked by uid 89); 23 Aug 2019 07:21:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=alex, H*i:sk:CAFyWVa, googlemail.com, googlemailcom X-HELO: mail-wm1-f44.google.com Received: from mail-wm1-f44.google.com (HELO mail-wm1-f44.google.com) (209.85.128.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Aug 2019 07:21:24 +0000 Received: by mail-wm1-f44.google.com with SMTP id e8so8668804wme.1 for ; Fri, 23 Aug 2019 00:21:23 -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=Ws7rY//05dY+3wnUrDxpE9CzRgDF4C5aKmdnKr0oEgE=; b=R+FPDAo1kFT0QjNBFduyl3L0UHAFiDcPNH/OCYNBsl41CDHU+vcIOeQjJJ5GbkKNEa XqAPx78ZGYdFE649I2WNGestfE90aVG2lOvdcgRbFoQnT2P+zx/gU3waJz73gL+e7ZaM S6PHKVhcJNLhzJSg7Mxv1mEfpi4PUPElK+xfth+vjUE/mdM6jo/W9ezZbPJRWcKJ9IJI 4kPImfEFysPoeDfxn0Ntif6/w7ibThX/I/4bt5QulZxpKJh2Oa8fGXy6z1fz8O9bvOUi Ro1JxqYfzlww7ROlcPReHl7V+udwpwrUlCyz4Qe0bR2DxvwOg/4wyEJY9IbR7EWUTWrm zlRw== 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 b136sm6476979wme.18.2019.08.23.00.21.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 00:21:21 -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 07:21:00 -0000 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> References: To: Jim Wilson X-SW-Source: 2019-08/txt/msg00193.txt.bz2 Hi Jim, > 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=20 A search for _Atomic in the latest (x86_64) psABI document shows no results. > 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=20 the non-_Atomic version.=20 e.g from 6.2.5 of n2176 (C18 draft) =E2=80=A2 27 Further, there is the _Atomic qualifier. The presence of the= _Atomic qualifier designates an atomic type. The size, representation, and= alignment of an atomic type need not be the same as those of the correspon= ding unqualified type. Therefore, this Standard explicitly uses the phrase = =E2=80=9Catomic, qualified or unqualified type=E2=80=9D whenever the atomic= version of a type is permitted along with the other qualified versions 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 _Atom= ic variants to the psABI=E2=80=A6.=20 =E2=80=A6 of course, it makes sense for the psABI maintainers to discuss wi= th 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 th= e 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 bac= kends is=20 =E2=80=9Cllvm/CODE_OWNERS.TXT=E2=80=9D which says that Alex Bradbury is the= code owner for the RISC-V backend. HTH, Iain > The original RISC-V bug report is at > https://github.com/riscv/riscv-elf-psabi-doc/pull/112 > There is a pointer to a gist with a larger testcase with RISC-V results. >=20 > Jim