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 31F21385703C for ; Mon, 8 Aug 2022 21:35:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31F21385703C Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 278LDoWX027703; Mon, 8 Aug 2022 21:35:36 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hua7hreru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Aug 2022 21:35:35 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 278LZ41o031835; Mon, 8 Aug 2022 21:35:35 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hua7hrer5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Aug 2022 21:35:35 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 278LKKMT029070; Mon, 8 Aug 2022 21:35:34 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma02dal.us.ibm.com with ESMTP id 3hsfx9ag0f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Aug 2022 21:35:34 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 278LZX1A66126128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Aug 2022 21:35:33 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EA00B124052; Mon, 8 Aug 2022 21:35:32 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 32DD2124053; Mon, 8 Aug 2022 21:35:32 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.225.181]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTPS; Mon, 8 Aug 2022 21:35:32 +0000 (GMT) Date: Mon, 8 Aug 2022 17:35:30 -0400 From: Michael Meissner To: Jonathan Wakely Cc: Michael Meissner , Nathan Sidwell , GCC Development , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , Jason Merrill , Mike Stump , Iain Sandoe , Joseph Myers , Tulio Magno Quites Machado Filho , Alan Modra , Nick Clifton , Jeff Law , Jakub Jelinek , Richard Biener , "David S. Miller" , "Carlos O'Donell" , GNU C Library Subject: Re: Potential upcoming changes in mangling to PowerPC GCC Message-ID: Mail-Followup-To: Michael Meissner , Jonathan Wakely , Nathan Sidwell , GCC Development , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , Jason Merrill , Mike Stump , Iain Sandoe , Joseph Myers , Tulio Magno Quites Machado Filho , Alan Modra , Nick Clifton , Jeff Law , Jakub Jelinek , Richard Biener , "David S. Miller" , Carlos O'Donell , GNU C Library References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: JXWph3ShbQwnFw-UYoVKAkjApGp_Z37r X-Proofpoint-ORIG-GUID: f4emqTClsImDhokZfdVCaDEBpWXUvXyq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-08_13,2022-08-08_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1015 impostorscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 phishscore=0 adultscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208080092 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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 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, 08 Aug 2022 21:35:43 -0000 On Thu, Aug 04, 2022 at 10:14:10PM +0100, Jonathan Wakely wrote: > On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc wrote: > > > > On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote: > > > Not a problem. I don't think I have anything to add- I presume you've > > > thought about (weak) aliases to deal with the problematic changes you > > > mention towards the end? > > > > I've thought about it. I know in the past we had weak aliases to do the > > support the same way when we had the last name mangling change. I know those > > aliases weren't popular back then. > > > > Part of the reason for asking is I don't have a sense for how library > > maintainers use the __float128 and __ibm128 keywords. Do they treat them as > > full fledged types, or are they just convenient ways to compile code with both > > names rather than building two modules, with the different long double types? > > > Within libstdc++ it's not just a minor convenience, it's 100% > necessary to refer to both kinds (IEEE 128 and IBM 128) in the same > translation unit. There are C++ classes with member functions taking > both types, e.g. > > struct Foo { > void f(__ibm128); > void f(__ieee128); > }; > > You can't do this by "building two modules" because it's a header and > you can't split the definition of a class across two different files. > And in many cases, it's a class template, so you can't even hide the > definition of the function in a .cc file, it has to be defined in the > header. So libstdc++ 100% requires a way to refer to "the type that is > long double" (which is easy, that's 'long double') and "the other > 128-bit type that isn't long double" (which is one of __ibm128 or > __ieee128). So we need to refer to *at least* one of __ibm128 or > __ieee128, and in some cases it's simpler to not refer to 'long > double' at all (because its meaning can change) and just refer to > __ibm128 and __ieee128 because those always mean the same thing. > > If the names or mangling for either of those types changes, it would > break libstdc++ and require more work just to restore the existing > functionality. I tend to agree that only having mangling for two 128-bit types (ieee and ibm), no matter what they are called is better than trying to support 3 separate types (explict ieee, explicit ibm, and whatever long double is). That way we don't have to come up with new mangling forms, which has backwards compatibility issues. But it is possible as distros move from having the default long double being IBM to being IEEE, we will see disconnect in user code, where they want to use long double and add an explicit __float128 type. I imagine if x86 ever flips the switch so that -mlong-double-128 is default (instead of -mlong-double-80), they would see the same issues between using __float128 and long double. And libstdc++ and glibc not using explicit long double is likely the best way to avoid all of the issues. There are still likely issues in moving from the current implementation, but it is simpler if we don't have to have 4 different mangling forms (the explicit forms, and the 2 forms for long double). -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com