From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 47C983858C50; Wed, 2 Nov 2022 02:39:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 47C983858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2A20rvTD022746; Wed, 2 Nov 2022 02:39:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : subject : message-id : mime-version : content-type; s=pp1; bh=PlvhN6DJRqd+21Jfm0TskyamVC1XUF/zLpS+8oc904M=; b=tGaz0ODURkm+lqhTzLUtL6u4tvJ0v3U32omtVXD8PmOO6Hbgd3LFDKgWmfHdUq6ZZOuV uTneo2N1X9szHlIq/lI/qL87F7gp4uds2M/w/yuXz1f/j3H8o6O8mG8OnkL+W8lwZ34z QBB/c3ifWMF2cLDAjMcetjpwX8uS5qqonLKJ883PRGngZnkkoVgtOkKKIhS3AyDoIjFG eoot1KT9iOkfvKh7ITEEfmxP9xWSTTXUCGDR8GRGihUBVMARwF7GgQDOeiTAkI5Iw5nh XAMnzCBKPtvj6Xl/MQe+jqk5SL/QuFOIEzk7/IIN8p0668+8z9Mjn56RrHZ0bksrMeHW cA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kjwjjw5ba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Nov 2022 02:39:09 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2A21buIu024844; Wed, 2 Nov 2022 02:39:09 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kjwjjw5b3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Nov 2022 02:39:09 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2A22aFAQ020015; Wed, 2 Nov 2022 02:39:08 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma01wdc.us.ibm.com with ESMTP id 3kgut9qy1k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Nov 2022 02:39:08 +0000 Received: from smtpav06.dal12v.mail.ibm.com ([9.208.128.130]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2A22d59Y16122282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Nov 2022 02:39:05 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E44ED58060; Wed, 2 Nov 2022 02:39:06 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 551F358055; Wed, 2 Nov 2022 02:39:06 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.5.6]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTPS; Wed, 2 Nov 2022 02:39:06 +0000 (GMT) Date: Tue, 1 Nov 2022 22:39:04 -0400 From: Michael Meissner To: gcc-patches@gcc.gnu.org, Michael Meissner , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , William Seurer Subject: Patch [0/3] for PR target/107299 (GCC does not build on PowerPC when long double is IEEE 128-bit) Message-ID: Mail-Followup-To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt , William Seurer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: _ekpjnH3mHLqS3L11VP5w6GV-xm9I3tp X-Proofpoint-GUID: hKAt4QtlPwCpxRqhl6NO2fq0jP0qu52p X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-01_12,2022-11-01_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 priorityscore=1501 phishscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211020013 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_MANYTO,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 List-Id: These 3 patches fix the problems with building GCC on PowerPC systems when long double is configured to use the IEEE 128-bit format. There are 3 patches in this patch set. The first two patches are required to fix the basic problem. The third patch fixes some issue that were noticed along the way. The basic issue is internally within GCC there are several types for 128-bit floating point. The types are: 1) The long double type (TFmode or possibly DFmode). In the normal case, long double is 128-bits (TFmode) and depending on the configuration switches and the switches passed by the user at compilation time, long double is either the 128-bit IBM double-double type or IEEE 128-bit. 2) The type for __ibm128. If long double is IBM 128-bit double-double, internally within the compiler, this type is the same as the long double type. If long double is either IEEE 128-bit or is 64-bit, then this type is a separate type. 3) The type for _Float128. This type is always IEEE 128-bit if it exists. While it is a separate internal type, currently if long double is IEEE 128-bit, this type uses TFmode once it gets to RTL, but within Gimple it is a separate type. If long double is not IEEE 128-bit, then this type uses KFmode. All of the f128 math functions defined by the compiler use this type. In the past, _Float128 was a C extended type, but now it is a part of the C/C++ 2x standards. 4) The type for __float128. The history is I implemented __float128 first, and several releases later, we added _Float128 as a standard C type. Unfortunately, I didn't think things through enough when _Float128 came out. Like __ibm128, it uses the long double type if long double is IEEE 128-bit, and now it uses the _Float128 type if long double is not IEEE 128-bit. IMHO, this is the major problem. The two IEEE 128-bit types should use the same type internally (or at least one should be a qualified type of the other). Before we started adding more support for _Float128, it mostly works, but now it doesn't with more optimizations being done. 5) The error occurs in building _mulkc3 in libgcc, when the TFmode type in the code is defined to use attribute((mode(TF))), but the functions that are called all have _Float128 arguments. These are separate types, and ultimately one of the consistancy checks fails because they are different types. There are 3 patches in this set: 1) The first patch rewrites how the complex 128-bit multiply and divide functions are done in the compiler. In the old scheme, essentially there were only two types ever being used, the long double type, and the not long double type. The original code would make the names called of these functions to be __multc3/__divtc3 or __mulkc3/__divkc3. This worked because there were only two types. With straightening out the types, so __float128/_Float128 is never the long double type, there are potentially 3-4 types. However, the C front end and the middle end code will not let use create two built-in functions that have the same name. So I ripped out this code, and I hopefully replaced it with cleaner code that is in patch #1. This patch needs to be in the compiler before the second patch can be installed. 2) The second patch fixes the problem of __float128 and _Float128 not being the same if long double is IEEE 128-bit. After this patch, both _Float128 and __float128 types will always use the KFmode type. The stdc++ library will not build if we use TFmode for these types due to the other changes. There is a minor codegen issue that if you explicitly use long double and call the F128 FMA (fused multiply-add) round to odd functions that are defined to use __float128/_Float128 arguments. While we might be able to optimize these later, I don't think it is important to optimize the use of long double instead of __float128/_Float128. Note, if you use the proper __float128/_Float128 types instead of long double, the code does the optimization. By doing this change, it also fixes two tests that have been broken on IEEE 128-bit long double systems (float128-cmp2-runnable.c and nan128-1.c). These two tests use __float128 variables and call nansq to create a signaling NaN. Nansq is defined to be __builtin_nansf128, which returns a _Float128 Nan. However, since in the current implementation before these patches, __float128 is a different type than _Float128 when long double is IEEE 128-bit, the machine independent code converts the signaling NaN into a non-signaling NaN. Since after these patches they are the same internal type, the signaling NaN is preserved. 3) This patch fixes two tests that were still failing after patches #1 and #2 were applied (convert-fp-128.c and pr85657-3.c). It fixes the conversions between the 128-bit floating point types. In the past, we would always call rs6000_expand_float128_convert to do all conversions. After this patch, the conversions between different types that have the same representation will be done in-line and not call rs6000_expand_float128_convert. In addition, in the past we missed some conversions, and the compiler would generate an external call, even though the types might have the same representation. After these patches, there are 3 specific tests and 1 set of tests that fail when using IEEE 128-bit long double: 1) fp128_conversions.c: I haven't looked at yet; 2) pr105334.c: This is a bug that __ibm128 doesn't work if the default long double is IEEE 128-bit and you use the options: -mlong-double-128 -msoft-float (i.e. no -mabi=ibmlongdouble). I believe I have patches for this floating around. 3) The g++.dg/cpp23/ext-floating1.C test is failing. I believe we need to dig in to fix PowerPC specific ISO C/C++ 2x _Float128 support. I have looked at it yet. 4) All/some of the G++ modules tests fail. This is PR 98645, and it is assigned to Nathan Sidwell. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com