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 ESMTP id 3458C3858D39 for ; Wed, 22 Sep 2021 15:02:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3458C3858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-564-gPZ8-gP1PjCzdMcpFwIFmA-1; Wed, 22 Sep 2021 11:02:23 -0400 X-MC-Unique: gPZ8-gP1PjCzdMcpFwIFmA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 38F4A100791E; Wed, 22 Sep 2021 15:02:22 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 74CAC5C3DF; Wed, 22 Sep 2021 15:02:21 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 18MF2HlW373004 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 17:02:18 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 18MF2Fua373003; Wed, 22 Sep 2021 17:02:15 +0200 Date: Wed, 22 Sep 2021 17:02:15 +0200 From: Jakub Jelinek To: Bill Schmidt Cc: will schmidt , GCC Patches , David Edelsohn , Segher Boessenkool , willschm@linux.ibm.com Subject: Re: [PATCH] rs6000: Add psabi diagnostic for C++ zero-width bit field ABI change (PR102024) Message-ID: <20210922150215.GE304296@tucnak> Reply-To: Jakub Jelinek References: <676699df-01c3-690a-d49f-8d00d1891246@linux.ibm.com> <189f5cfa4f77fc71a12f5d57df6320256dc57cd7.camel@vnet.ibm.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP 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, 22 Sep 2021 15:02:26 -0000 On Wed, Sep 22, 2021 at 09:43:23AM -0500, Bill Schmidt wrote: > > How previously? is this one that will need all the backports? > > No, the change happened recently on trunk. It is actually more complex. Both C and C++ FEs thought they were removing zero bit fields, but neither did that, then the non-working code from C FE has been removed, and finally in 4.5 the C++ FE has been "fixed" to remove zero bit fields "correctly". And 12 is going to remove the removal, but marks FIELD_DECLs that were in 4.5-11 removed and now aren't for -Wpsabi purposes. So, for most backends, C and C++ was ABI compatible in presence of :0 initially, then for several got incompatible in 4.5 and now is time to decide for each backend what to do according to their psABI, if :0 should be ignored or not during the function arg/return value passing decisions. > > > --- a/gcc/config/rs6000/rs6000-call.c > > > +++ b/gcc/config/rs6000/rs6000-call.c > > > @@ -6227,7 +6227,7 @@ const struct altivec_builtin_types altivec_overloaded_builtins[] = { > > > static int > > > rs6000_aggregate_candidate (const_tree type, machine_mode *modep, > > > - int *empty_base_seen) > > > + int *empty_base_seen, int *zero_width_bf_seen) > > > { > > > machine_mode mode; > > > HOST_WIDE_INT size; > > > @@ -6298,7 +6298,8 @@ rs6000_aggregate_candidate (const_tree type, machine_mode *modep, > > > return -1; > > > count = rs6000_aggregate_candidate (TREE_TYPE (type), modep, > > > - empty_base_seen); > > > + empty_base_seen, > > > + zero_width_bf_seen); > > > if (count == -1 > > > || !index > > > || !TYPE_MAX_VALUE (index) > > > @@ -6336,6 +6337,12 @@ rs6000_aggregate_candidate (const_tree type, machine_mode *modep, > > > if (TREE_CODE (field) != FIELD_DECL) > > > continue; > > > + if (DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD (field)) > > > + { > > > + *zero_width_bf_seen = 1; > > > + continue; > > > + } So, from what you wrote, :0 in the ppc* psABIs the intent is that :0 is not ignored, right? In that case I don't really understand the above (the continue in particular). Because the continue means it is ignored for C++ and not ignored for C, so basically you return to the 4.5-11 ABI incompatibility between C and C++. C++ :0 will have DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD set, C :0 will not... Jakub