From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7A9C73889E2C for ; Thu, 25 May 2023 08:23:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A9C73889E2C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685003019; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pyxV+UQILAcMxYys2Q9eRNcx+2SdAFy9HZ3u0Gt4nS0=; b=MqlBp9dIW9OgND0uwhfra4I+elCgyJc2RA0XQBepD13l1Looj2jHmbVNtyTFI7MTOZozo7 LGFqO01kxiy9jyEx6mwsNr+1FsBQPR33V7zNWs7t6yg80Xqka9DOz9tMz//keQWWIy/qe+ sM5AuQdxokLiBPQuXoKnrNtgVeT4N9I= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-550-bwqV1MtYMJCetVoINl3NdA-1; Thu, 25 May 2023 04:23:37 -0400 X-MC-Unique: bwqV1MtYMJCetVoINl3NdA-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-4edd54a0eaeso1236790e87.0 for ; Thu, 25 May 2023 01:23:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685003015; x=1687595015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pyxV+UQILAcMxYys2Q9eRNcx+2SdAFy9HZ3u0Gt4nS0=; b=clAq+vHj06QJk70U3WWV8t8EJM8S4AZg2T7Z3Jum7kOH0yqEyQ5VBjvCo9Cy8QaT36 Idiz7mo0uJ5JujwQxYO65J/vWdlWe5aP42N9QmFC+Bnxz+QKnkLSBYbOUgyOah4jehy1 aK93K4jgmqFb4SW8qOePrmXPoN+1JSMTBclwn+WfwG1vBUzwrld33ODe22cLEnhQ7JFV uVs3Xaxr6pvUj987n4RiplJL1pVAEJn5JdXoAtVIBm3ubLKxD3AD8rwSM1+YDQBbbyo9 mQHC8yX9ZNplHD+zdL+dJIb75Iv4HAgKaXcKKW219f2+gvOs46GJWiJOfJqLrqIPdPX2 23RQ== X-Gm-Message-State: AC+VfDx5NNruaRA7pDHNNzcOiopnZE9tko5hZCOtW4Oz2z+V3vhaBdsY /F0Dk0QGjMvUidhqp6+uShR6ameI7qUNdoGTiE6mKJHRpd2KINQUEalTP1a4ejakjbSFgjlcsBo NAy33ajcTamq7l0StTztl71BD+Gs5I+ts6Q== X-Received: by 2002:a05:651c:1047:b0:2af:23c2:5dce with SMTP id x7-20020a05651c104700b002af23c25dcemr946415ljm.25.1685003015840; Thu, 25 May 2023 01:23:35 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ59Bns9Xnt8ye8BSJas26RwU58ln5N+/2BMYmQxxtFonwGzTXI8kzB3+WCQs9rCOehNTtN5sxGb2AZKZ9xN06g= X-Received: by 2002:a05:651c:1047:b0:2af:23c2:5dce with SMTP id x7-20020a05651c104700b002af23c25dcemr946408ljm.25.1685003015416; Thu, 25 May 2023 01:23:35 -0700 (PDT) MIME-Version: 1.0 References: <20230524060407.19181-1-chenglulu@loongson.cn> <2d33bf204b0d59f16df8714123ee812be5754617.camel@xry111.site> <356c3dfd86b82689483fc96f97790909a2e57c47.camel@xry111.site> In-Reply-To: From: Jonathan Wakely Date: Thu, 25 May 2023 09:23:23 +0100 Message-ID: Subject: Re: [PATCH] LoongArch: Fix the problem of structure parameter passing in C++. This structure has empty structure members and less than three floating point members. To: Jason Merrill Cc: Xi Ruoyao , Lulu Cheng , gcc-patches@gcc.gnu.org, i@xen0n.name, xuchenghua@loongson.cn X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000002e00f005fc805607" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000002e00f005fc805607 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 24 May 2023 at 21:15, Jason Merrill wrote: > On Wed, May 24, 2023 at 5:00=E2=80=AFAM Jonathan Wakely via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > >> On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote: >> >> > Wang Lei raised some concerns about Itanium C++ ABI, so let's ask a C++ >> > expert here... >> > >> > Jonathan: AFAIK the standard and the Itanium ABI treats an empty class >> > as size 1 >> >> Only as a complete object, not as a subobject. >> > > Also as a data member subobject. > > >> > in order to guarantee unique address, so for the following: >> > >> > class Empty {}; >> > class Test { Empty empty; double a, b; }; >> >> There is no need to have a unique address here, so Test::empty and Test:= :a >> have the same address. It's a potentially-overlapping subobject. >> >> For the Itanium ABI, sizeof(Test) =3D=3D 2 * sizeof(double). >> > > That would be true if Test::empty were marked [[no_unique_address]], but > without that attribute, sizeof(Test) is actually 3 * sizeof(double). > Doh, yes. > > >> > When we pass "Test" via registers, we may only allocate the registers >> > for Test::a and Test::b, and complete ignore Test::empty because there >> > is no addresses of registers. Is this correct or not? >> >> I think that's a decision for the loongarch psABI. In principle, there's >> no >> reason a register has to be used to pass Test::empty, since you can't re= ad >> from it or write to it. >> > > Agreed. The Itanium C++ ABI has nothing to say about how registers are > allocated for parameter passing; this is a matter for the psABI. > > And there is no need for a psABI to allocate a register for Test::empty > because it contains no data. > > In the x86_64 psABI, Test above is passed in memory because of its size > ("the size of the aggregate exceeds two eightbytes..."). But > > struct Test2 { Empty empty; double a; }; > > is passed in a single floating-point register; the Test2::empty subobject > is not passed anywhere, because its eightbyte is classified as NO_CLASS, > because there is no actual data there. > > I know nothing about the LoongArch psABI, but going out of your way to > assign a register to an empty class seems like a mistake. > > > On Wed, 2023-05-24 at 14:45 +0800, Xi Ruoyao via Gcc-patches wrote: >> > > On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote: >> > > > An empty struct type that is not non-trivial for the purposes of >> > > > calls >> > > > will be treated as though it were the following C type: >> > > > >> > > > struct { >> > > > char c; >> > > > }; >> > > > >> > > > Before this patch was added, a structure parameter containing an >> > > > empty structure and >> > > > less than three floating-point members was passed through one or t= wo >> > > > floating-point >> > > > registers, while nested empty structures are ignored. Which did not >> > > > conform to the >> > > > calling convention. >> > > >> > > No, it's a deliberate decision I've made in >> > > https://gcc.gnu.org/r12-8294. And we already agreed "the ABI needs >> to >> > > be updated" when we applied r12-8294, but I've never improved my >> > > English >> > > skill to revise the ABI myself :(. >> > > >> > > We are also using the same "de-facto" ABI throwing away the empty >> > > struct >> > > for Clang++ (https://reviews.llvm.org/D132285). So we should update >> > > the >> > > spec here, instead of changing every implementation. >> > > >> > > The C++ standard treats the empty struct as size 1 for ensuring the >> > > semantics of pointer comparison operations. When we pass it through >> > > the >> > > registers, there is no need to really consider the empty field becau= se >> > > there is no pointers to registers. >> > > >> > >> > >> >> --0000000000002e00f005fc805607--