From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
[IPv6:2a00:1450:4864:20::534])
by sourceware.org (Postfix) with ESMTPS id C7F9A3858405
for ; Wed, 30 Mar 2022 11:00:55 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C7F9A3858405
Received: by mail-ed1-x534.google.com with SMTP id h1so23967344edj.1
for ; Wed, 30 Mar 2022 04:00:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=3VvSe7caTIbMNVBe9JGKCvifVWURqy1z4AN0kmwNjVI=;
b=DlNY21EsnAC8Hi+IovHdNukWt7HoW0sCD7dmAdzgXMkCPH/KuC68+Uooufp/TDSz4b
kQEM92OxWTng6vJoDLOrb3FnQwPbNSM6idIW8r5GpzbWdNtgXFBsshjuP2yz0b+4l4qj
mskhKG//xVLyOhZZyy0Xd9Oykn7S7JFQXWRyI1cs5dQNaFVy6DyNmh9h5ohd/REJuX8O
bsjwNvmq9NLrlDKnIyx2S9icYcFziHA+sThZQQ+LFSWxA3Ma6WGvvcQJ5RQTtW/110eQ
8ZiAlsgU9p9/oQLJqEfVF7gl8aSwqN9SBCRDLSkqyCR//Qu7CJYQCpo/dA1H0DB7tgrN
oheQ==
X-Gm-Message-State: AOAM533MJhWH52+Ug8XTPxNs7DBBvCnGHLc3h10YhLUkgxBrVf9Gpce7
JVxI/zD4FOliQ/KOnoCB4Ij90aqPyszyhIHgFVk=
X-Google-Smtp-Source: ABdhPJwW7QI1fNAnYgwZa65R5HW/O6HL+JbDjSiOVijaqoeqHpIaL8jzlSX3ej+bjGx2r2H68Se3KxWczywrpNbvKms=
X-Received: by 2002:a50:a41a:0:b0:419:d2b:8391 with SMTP id
u26-20020a50a41a000000b004190d2b8391mr9984835edb.390.1648638054383; Wed, 30
Mar 2022 04:00:54 -0700 (PDT)
MIME-Version: 1.0
References:
In-Reply-To:
From: Richard Biener
Date: Wed, 30 Mar 2022 13:00:43 +0200
Message-ID:
Subject: Re: [wwwdocs] Document zero width bit-field passing ABI changes in
gcc-12/changes.html [PR104796]
To: Jakub Jelinek
Cc: GCC Patches
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0,
KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP,
T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 30 Mar 2022 11:00:58 -0000
On Wed, Mar 30, 2022 at 12:08 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> This patch documents the PR102024 ABI changes.
> The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
> diagnostics.
> Ok for wwwdocs?
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 689feeba..dc0e4074 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -28,6 +28,31 @@ a work-in-progress.
>
> Caveats
>
> + -
> + An ABI incompatibility between C and
> + C++ when passing or returning by value certain aggregates with zero
> + width bit-fields has been discovered on various targets.
"containing zero width bit-fields"?
> + As mentioned in PR102024,
> + since the PR42217 fix in
> + GCC 4.5 the C++ front-end has been removing zero width bit-fields
> + from the internal representation of the aggregates after the layout of those
> + aggregates, but the C front-end kept them, so passing e.g.
> +
struct S { float a; int : 0; float b; }
or
> + struct T { float c; int : 0; }
by value could differ
> + between C and C++. Starting with GCC 12 the C++ front-end no longer
> + removes those bit-fields from the internal representation and
> + per clarified psABI some targets have been changed, so that they
> + either ignore those bit-fields in the argument passing by value
> + decisions in both C and C++, or they always take them into account.
> + x86-64, ARM and AArch64 will always ignore them (so there is
> + a C ABI incompatibility between GCC 11 and earlier with GCC 12 or
> + later), PowerPC64 ELFv2 and S/390 always take them into account
> + (so there is a C++ ABI incompatibility, GCC 4.4 and earlier compatible
> + with GCC 12 or later, incompatible with GCC 4.5 through GCC 11).
> + RISC-V has changed the handling of these already starting with GCC 10.
> + GCC 12 on the above targets will report such incompatibilities as
> + warnings or other diagnostics unless -Wno-psabi
is used.
> +
Otherwise LGTM.
The case with float a; int :0; float b; looks quite artificial - are there cases
where { int a0 : 24; int a1 : 8; int :0; int b0 : 24; int b1 : 8; }
are affected? Thus
cases where people might actually use :0 which is inbetween bitfields? At
least I can't convince GCC on x86_64 to pass those differently,
struct X { long a0 : 24; long a1 : 8; long :0; long b0 : 24; long b1 : 8; };
struct X foo (struct X x)
{
return x;
}
seem to pass in %rsi/%rdi and return in %rax/%rdx with both GCC 11 and trunk.
Richard.
> -
> C:
> Computed gotos require a pointer type now.
>
> Jakub
>