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 4E16A385703C for ; Mon, 8 Aug 2022 21:44:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4E16A385703C 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 278LMYTh018935; Mon, 8 Aug 2022 21:44:43 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3huabngf5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Aug 2022 21:44:42 +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 278LMja1019704; Mon, 8 Aug 2022 21:44:42 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3huabngf5j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Aug 2022 21:44:42 +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 278LKI9l028928; Mon, 8 Aug 2022 21:44:40 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma02dal.us.ibm.com with ESMTP id 3hsfx9ahfp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Aug 2022 21:44:40 +0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 278Lidc626083700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Aug 2022 21:44:39 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 57F8A6E050; Mon, 8 Aug 2022 21:44:39 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EEB646E04E; Mon, 8 Aug 2022 21:44:37 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.225.181]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTPS; Mon, 8 Aug 2022 21:44:37 +0000 (GMT) Date: Mon, 8 Aug 2022 17:44:36 -0400 From: Michael Meissner To: Segher Boessenkool Cc: Michael Meissner , GCC Development , "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-alpha@sourceware.org Subject: Re: Resend: Potential upcoming changes in mangling to PowerPC GCC Message-ID: Mail-Followup-To: Michael Meissner , Segher Boessenkool , GCC Development , "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-alpha@sourceware.org References: <20220804205355.GO25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220804205355.GO25951@gate.crashing.org> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 5IwiUFrRSS8_8CR47DDsQznaFiY-nMyH X-Proofpoint-GUID: IzVPMocxT6-UEsX1dfmgul-VvF2Pvand 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 spamscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208080092 X-Spam-Status: No, score=-4.2 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:44:47 -0000 On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote: > > 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 __ieee128, which (unlike __float128) explicitly is IEEE QP float > (and as a bonus that is obvious in every context, too). > > > 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. > > It would be a lot simpler and less roundabout and inside out if we could > do this the other way around: start with the QP float and double-double > types and modes, and point the long double type and TFmode at that. But > alas. Yes if we could go back 5 years it would have been simpler to do that way. But we are stuck with moving what we have forward. > > 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. > > So you are saying __float128 and _Float128 should *not* be separate > types? Or, the testcases are buggy, make unwarranted assumptions? I am saying right now, they are separate types when -mabi=ieeelongdouble is used. They are the same type when -mabi=ibmlongdouble is used. I think they should be the same type, no matter which way long double is defined. But there are a bunch of assumptions within the compiler that need to be changed due to these assumptions. > > > 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. > > So fix that? It is a clear bug. It isn't so simple, since as I've said in the past, it essentially will require a gimple pass to determine that types are used to set the bits. Right now, because the bits are being set because of modes used, there are false positives. If you are volunteering to do the work go ahead. > > > 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) > > It cannot always use IFmode? Generic code uses TFmode for long double > (which can be double-double). My point is __ibm128 can potentionally be separate and always use IFmode. Hence my question. > Please open PRs for the broken testcases (one for each, unless of course > you are confident they are the same problems: it is much easier to join > PRs than to split them). Of course, but I want to scope out the work. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com