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 4B8803858C39 for ; Wed, 3 Aug 2022 22:21:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B8803858C39 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 273LlKJi029435; Wed, 3 Aug 2022 22:21:41 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3hr187rv5x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Aug 2022 22:21:40 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 273LltEw030391; Wed, 3 Aug 2022 22:21:40 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3hr187rv5h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Aug 2022 22:21:40 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 273MLTMG002647; Wed, 3 Aug 2022 22:21:39 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma05wdc.us.ibm.com with ESMTP id 3hmv99tt17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Aug 2022 22:21:39 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 273MLcYe3867136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Aug 2022 22:21:38 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 958FB112061; Wed, 3 Aug 2022 22:21:38 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EA572112064; Wed, 3 Aug 2022 22:21:37 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.225.181]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS; Wed, 3 Aug 2022 22:21:37 +0000 (GMT) Date: Wed, 3 Aug 2022 18:21:36 -0400 From: Michael Meissner To: GCC Development , Michael Meissner , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , Jason Merrill , Nathan Sidwell , 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" Cc: libc-maintainers mailing list Subject: Potential upcoming changes in mangling to PowerPC GCC Message-ID: Mail-Followup-To: Michael Meissner , GCC Development , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , Jason Merrill , Nathan Sidwell , 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 , libc-maintainers mailing list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-GUID: RUwpIHHKPb9yKLnLZ3aJzqIKipXbZGeh X-Proofpoint-ORIG-GUID: ubWB3mO3tcBGhuDuci9n-pC5uFrLZ49Y 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-03_06,2022-08-02_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 mlxscore=0 bulkscore=0 phishscore=0 adultscore=0 clxscore=1011 malwarescore=0 suspectscore=0 spamscore=0 mlxlogscore=743 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208030093 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_MANYTO, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Wed, 03 Aug 2022 22:21:46 -0000 Note, I tried to send this out before, but it didn't seem to go out. Sorry if you got it twice. Sorry for the scatter shot mail that covers C++, Objective C++, Glibc, etc. developers, but I wanted to discuss and get buy-in on changes to the PowerPC GCC compiler that I would like to do in the endless project of supporting IEEE 128-bit floating point. Sorry if I spammed your inbox if this doesn't concern you. At the moment, GCC 12 on the server PowerPC systems supports multiple 128-bit floating point types: * _Float128 (in the C language): IEEE 128-bit floating point; * __float128 (in the C and C++ languages): IEEE 128-bit floating point; * long double: One of IEEE 128-bit floating, IBM 128-bit floating point, or 64-bit floating point; (and) * __ibm128: Explicit IBM 128-bit floating point. And there are 3 modes: * KFmode: IEEE 128-bit floating point; * IFmode: IBM 128-bit floating point; (and) * TFmode: Either IEEE 128-bit or IBM 128-bit floating point. But internally within the compiler there are mostly only two separate types, an IEEE 128-bit and IBM 128-bit floating point. If a file is compiled when long double uses the IEEE 128-bit floating point type, then the __float128 type is the long double type and it uses the TFmode mode. And while the _Float128 type is distinct from long double, it also uses TFmode. The __ibm128 type is distinct, and it uses IFmode. If a file is compiled when long double uses IBM 128-bit floating point, then the __float128 type uses the _Float128 type, and both types use KFmode. The __ibm128 type uses the long double type, and both types use TFmode. While things mostly work with this setup, there are some things that don't work as well. For example, 3 of the tests fail when you are using a system like Fedora 36 where IEEE 128-bit long double is default. These 3 tests use the 'nanqs' built-in function, which is mapped to 'nanf128s' and it delivers a _Float128 signaling NaN. But since __float128 uses a different type, the signaling NaN is converted and it loses the signaling property. The tests that fail are: * gcc.dg/torture/float128-nan.c * gcc.target/powerpc/nan128-1.c * gcc.target/powerpc/pr105334.c In addition, it would be nice if we could refine the setting of bits in the ELF header so that if you pass an explicit __float128 or __ibm128 object, it doesn't set the bits that you used long double of the appropriate type. But the code that sets these bits is done in the RTL stages, and it only looks at modes, not at types. Now, I'm working on patches to 'do the right thing': * Make _Float128 and __float128 always use the same distinct type and always use KFmode; * Make __ibm128 use a distinct type and always use IFmode; (and) * Long double would not share an internal type with either _Float128, __float128, or __ibm128. It would always use TFmode. One of the issues that comes up is the mangling support. I wanted to get buy-in on the solutions from the affected users: Because long double mangles the same as either __float128 or __ibm128, you cannot write programs like: double convert (__ibm128 x) { return x; } double convert (__float128 x) { return x; } double convert (long double x) { return x; } You would have to write on a system with long double being IBM 128-bit: double convert (__float128 x) { return x; } double convert (long double x) { return x; } or on a system with long double being IEEE 128-bit: double convert (__ibm128 x) { return x; } double convert (long double x) { return x; } At the moment, the mangling rules are: * If the type uses the IBM 128-bit encoding, use "g" for mangling; * If the type uses the IEEE 128-bit encoding, use "u9__ieee128" for mangling. I would suggest at least adding the rule: * If the type is explicitly __ibm128, use "u8__ibm128" for the mangling, and if it is long double that uses the IBM 128-bit encoding, continue to use "g" for the mangling. This shows up in the test suite g++.target/powerpc/pr85657.C. We probably should think about the reverse case of separating explict __float128 from long double that happens to use the IEEE 128-bit encoding. I suspect the right solution is to change the mangling on __float128 and leave long double alone. If so, any ideas on the mangling we should use? Perhaps we should use "DF128" which is the mangling for ISO/IEC TS 18661 _Float type. But in changing the mangling, we have the potential to create compatibility issues, of code compiled with previous GCC's that use explicit __ibm128 and __float128 keywords. I don't how the users of these keywords (i.e. typically libstdc++ and glibc developers, but potentially others as well). -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com