From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 910BF385E837 for ; Mon, 21 Mar 2022 21:50:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 910BF385E837 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22LIwZ4G026242; Mon, 21 Mar 2022 21:50:09 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3exf1v6bmk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 21:50:09 +0000 Received: from m0098413.ppops.net (m0098413.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 22LLn6QI030764; Mon, 21 Mar 2022 21:50:08 GMT Received: from ppma05fra.de.ibm.com (6c.4a.5195.ip4.static.sl-reverse.com [149.81.74.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 3exf1v6bm3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 21:50:08 +0000 Received: from pps.filterd (ppma05fra.de.ibm.com [127.0.0.1]) by ppma05fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 22LLiDAK014976; Mon, 21 Mar 2022 21:50:06 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma05fra.de.ibm.com with ESMTP id 3ew6t9c4gu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 21:50:06 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22LLo4IM51511806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Mar 2022 21:50:04 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 214B7A404D; Mon, 21 Mar 2022 21:50:04 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C2548A4040; Mon, 21 Mar 2022 21:50:03 +0000 (GMT) Received: from [9.171.48.12] (unknown [9.171.48.12]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 21 Mar 2022 21:50:03 +0000 (GMT) Message-ID: <3cb303d6-9371-d86b-bbf6-be32b6c251e0@linux.ibm.com> Date: Mon, 21 Mar 2022 22:50:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Urgent GCC ABI backend maintainer ping re zero width bitfield passing (PR102024) Content-Language: en-US To: Jakub Jelinek , Richard Earnshaw , Richard Sandiford , Kyrylo Tkachov , Ulrich Weigand , Eric Botcazou Cc: gcc@gcc.gnu.org References: From: Andreas Krebbel In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: FlTN6cvq8LiUmyBc72feMMzsMIHqXrbF X-Proofpoint-GUID: 5boPI6LwIDmYR0DWcqUwKlPic1-707dZ Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-21_09,2022-03-21_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 suspectscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 malwarescore=0 clxscore=1011 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203210137 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_MANYTO, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 21:50:14 -0000 On 3/21/22 17:28, Jakub Jelinek wrote: > Hi! > > I'd like to ping port maintainers about > https://gcc.gnu.org/PR102024 > > As I wrote, the int : 0 bitfields are present early in the TYPE_FIELDS > during structure layout and intentionally affect the layout. > We had some code to remove those from TYPE_FIELDS chains in the C and C++ > FEs, but for C that removal never worked correctly (never removed any) > and the non-working removal was eventually removed. For C++ it > didn't initially work either, but for GCC 4.5 that was fixed in PR42217, > so on various backends where TYPE_FIELDS are analyzed for how to pass or > return certain aggregates starting with GCC 4.5 the C++ and C ABI diverged. > In August, I have removed that zero width bitfield removal from C++ FE > as the FE needs to take those bitfields into account later on as well. > > The x86_64 backend was changed in r12-6418-g3159da6c46 to match recently > approved clarification of the x86-64 psABI and the zero width bitfields > are now ignored for both C and C++ (so an ABI change for C from 11.x and > earlier to 12.x and for C++ from GCC 4.4 and earlier to 4.5 and later) > with a -Wpsabi diagnostics about it. > > The rs6000 backend was changed in r12-3843-g16e3d6b8b2 to never ignore > those bitfields (so no ABI change for C, for C++ ...-4.4 and 12+ are > ABI incompatible with 4.5 through 11.x; note, it affects I think just > ppc64le ABI, which didn't really exist before 4.8 I think) and diagnostics > has been added about the ABI change. > > As I wrote in the PR, I believe most of the GCC backends are unaffected, > x86_64 and rs6000 are handled, riscv was changed already in GCC 10 to > ignore those bitfields and emit a -Wpsabi diagnostics. > > I can see code-generation differences certainly on armv7hl and aarch64. > ia64, iq2000, mips, s390 and sparc are maybe affected, haven't checked. On s390 we walk the field chain to figure out whether it is a struct with a single floating point field. Consequently I see different code being generated by g++ for { float a; int :0; } which is passed in a floating point register with g++ 11 and in memory with g++ 12. I'm not sure what is best for our target. I'll try to come back with an answer soon. Bye, Andreas > > Simple testcase could be e.g.: > struct S { float a; int : 0; float b; }; > > __attribute__((noipa)) struct S > foo (struct S x) > { > return x; > } > > void > bar (void) > { > struct S s = { 0.0f, 0.0f }; > foo (s); > } > where one should look at the argument and return value passing > in GCC 11 C, GCC 11 C++, GCC trunk C, GCC trunk C++. > > The FE now sets bits on the bitfields that make it possible to > differentiate between the different cases, so each port may decide to do > one of the 3 things: > 1) keep ABI exactly compatible between GCC 11 and 12, which means > C and C++ will continue to be incompatible > 2) keep the G++ 4.5 through 11 ABI of ignoring zero width bitfields and > change C ABI > 3) keep the GCC < 11 C ABI of not ignoring zero width bitfields and > change the C++ ABI (which means restoring ABI compatibility in > this regard between G++ 4.4 and earlier with G++ 12 and later) > Furthermore, it would be very nice to emit -Wpsabi diagnostics for the > changed ABI unless 1) is decided. > One should take into account psABI as well as what other compilers do. > > The current state of GCC trunk is that 3) is done except that x86_64 > did 2) and riscv did 2 already for GCC 10 and all of x86_64, riscv and > rs6000 emit -Wpsabi diagnostics (though I think rs6000 doesn't guard > it with -Wpsabi). > > I can help with the backend implementations if needed, but I can't > decide which possibility you want to choose for each backend. > It would be really nice to decide about this soon, because changing > the ABI in GCC 12 only to change it again in GCC 13 doesn't look much > desirable and even if 3) is the choice, it is really nice to have > some diagnostics about ABI changes. > > Thanks > > Jakub >