From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 1969D3858401 for ; Wed, 22 Sep 2021 20:30:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1969D3858401 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 18MK4Pwh034248; Wed, 22 Sep 2021 16:30:53 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3b88xdbncd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 16:30:52 -0400 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 18MKLw7N038814; Wed, 22 Sep 2021 16:30:52 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 3b88xdbnbw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 16:30:52 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 18MKHQrE026902; Wed, 22 Sep 2021 20:30:51 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma03dal.us.ibm.com with ESMTP id 3b7q6fvjws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 20:30:51 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 18MKUooO35783022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Sep 2021 20:30:50 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF213136066; Wed, 22 Sep 2021 20:30:49 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B4764136055; Wed, 22 Sep 2021 20:30:49 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.211.85.128]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 22 Sep 2021 20:30:49 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH] rs6000: Add psabi diagnostic for C++ zero-width bit field ABI change (PR102024) To: Jakub Jelinek , GCC Patches , Segher Boessenkool , David Edelsohn , willschm@linux.ibm.com References: <676699df-01c3-690a-d49f-8d00d1891246@linux.ibm.com> <189f5cfa4f77fc71a12f5d57df6320256dc57cd7.camel@vnet.ibm.com> <20210922150215.GE304296@tucnak> <20210922163313.GF304296@tucnak> From: Bill Schmidt Message-ID: <3c52b3b4-e863-ba06-9c2c-33e49f216f39@linux.ibm.com> Date: Wed, 22 Sep 2021 15:30:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210922163313.GF304296@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-GUID: QsjuboIQjAvb33JQasP5f8zCPz232vW3 X-Proofpoint-ORIG-GUID: pTImAOOUtKNdvesdtiY8SJeExVMX3Io8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-22_07,2021-09-22_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 spamscore=0 phishscore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109200000 definitions=main-2109220128 X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, 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 20:30:55 -0000 Hi Jakub, On 9/22/21 11:33 AM, Jakub Jelinek wrote: > On Wed, Sep 22, 2021 at 05:02:15PM +0200, Jakub Jelinek via Gcc-patches wrote: >>>>> @@ -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... > To be more precise, I'd expect what most targets want to do for the > actual ABI decisions not to use DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD at all. > I.e. do: > if (TREE_CODE (field) != FIELD_DECL) > continue; > if (DECL_BIT_FIELD (field) && integer_zerop (DECL_SIZE (field))) > { > // :0 > // in some psABIs, ignore it, i.e. continue; > // in others psABIs, take them into account, i.e. do nothing. > } > and use DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD only for the -Wpsabi purposes. > > The only exception would be for targets that decide to keep GCC 4.5-11 > compatibility with the C incompatible with C++. I think you're misunderstanding what I'm trying to do with this patch.  I am not changing the code generation at all (your patch did that).  All I'm doing is detecting when the old code generation and new code generation will differ, and emitting a diagnostic in that case. The way I do that is to allow rs6000_aggregate_candidate to *think* that something is a homogeneous aggregate even when zero-width bitfields are present (hence the continue), but record the fact that we saw one.  This gives the same answer as we gave before your patch.  Then, in rs6000_discover_homogeneous_aggregate, once we think we have a homogeneous aggregate, we check whether we actually had a zero-width bitfield present.  If so, then we diagnose the change in code generation and return false, indicating that we didn't actually find a homogeneous aggregate.  Other than the diagnostic, this matches the behavior after your patch. I've verified that we didn't change code generation for C code with zero-width bitfields as a result of either your patch or mine. Before and after, a C struct containing a zero-width bitfield causes us to avoid generating code for a homogeneous aggregate, just as we do for C++ after your patch. I hope this helps clear things up, and I apologize for not giving a better description of my intent. Thanks! Bill > > Jakub >