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 8B58E38319E1; Wed, 14 Dec 2022 10:11:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B58E38319E1 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 (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BEA9oiL026381; Wed, 14 Dec 2022 10:11:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=jA4CW572OWOa+Nu4TUcHyXrBHHLDsgRyKCzxptKkrco=; b=bo9NhhgaasJMMv/sW4Yr9sDaLDZpoSd889WuyZYGFrAaEFii7AAmnnHowwDkoPNYgSoa 6o78vaItoct+UqIBOwIl2m2MJ+YKtzJAAiKQieb3fbCzFhG87js2BlFuAepmLgJHDNhF p00n4IZkiE7GMSb5BnN7gxPdm2xCbKzhUUelVyky5z461V4jLm75qQHshkV/1GD+TGiM SbMZQMQovrJQcyxUDgx/0UGjRjpmOcu1ouVmTnp/IDcS6ZH+X8UpyvAK/FlsRCODa4EL 2DnytqMvH31IUcunDkfHKPUR/YERkz3AuTmNzra7eIclxPWHwmGryxozmZV+zmNThIrw xw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfc6vgcbf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 10:11:38 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BEAAEoP027682; Wed, 14 Dec 2022 10:11:37 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfc6vgcb3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 10:11:37 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BE9wOQO023379; Wed, 14 Dec 2022 10:11:35 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma03ams.nl.ibm.com (PPS) with ESMTPS id 3meyjbgw6k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 10:11:35 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BEABVmG32178672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Dec 2022 10:11:31 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C6E3020067; Wed, 14 Dec 2022 10:11:31 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6740B20071; Wed, 14 Dec 2022 10:11:28 +0000 (GMT) Received: from [9.197.253.236] (unknown [9.197.253.236]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 14 Dec 2022 10:11:28 +0000 (GMT) Message-ID: <3cbaa3d2-4327-c62a-2904-eac5ca506d20@linux.ibm.com> Date: Wed, 14 Dec 2022 18:11:26 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299 Content-Language: en-US To: Jakub Jelinek Cc: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: hMWsR0pVKjVnNqCZkFJBCHZQVHP06cc5 X-Proofpoint-ORIG-GUID: Xo9XRyoU6bmObf7PzcseIc6fcQ2r8cEu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-14_04,2022-12-13_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 adultscore=0 malwarescore=0 bulkscore=0 mlxscore=0 clxscore=1015 spamscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212140080 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,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: Hi Jakub, Thanks for the comments! on 2022/12/14 17:36, Jakub Jelinek wrote: > On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote: >> on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote: >>> Hi Mike, >>> >>> Thanks for fixing this, some comments are inlined below. >>> >>> on 2022/11/2 10:42, Michael Meissner wrote: >>>> This patch fixes the issue that GCC cannot build when the default long double >>>> is IEEE 128-bit. It fails in building libgcc, specifically when it is trying >>>> to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc >>>> during the evrp pass. Ultimately it is failing because the code declared the >>>> type to use TFmode but it used F128 functions (i.e. KFmode). >> >> By further looking into this, I found that though __float128 and _Float128 types >> are two different types, they have the same mode TFmode, the unexpected thing is >> these two types have different precision. I noticed it's due to the "workaround" >> in build_common_tree_nodes: >> >> /* Work around the rs6000 KFmode having precision 113 not >> 128. */ >> const struct real_format *fmt = REAL_MODE_FORMAT (mode); >> gcc_assert (fmt->b == 2 && fmt->emin + fmt->emax == 3); >> int min_precision = fmt->p + ceil_log2 (fmt->emax - fmt->emin); >> if (!extended) >> gcc_assert (min_precision == n); >> if (precision < min_precision) >> precision = min_precision; >> >> Since function useless_type_conversion_p considers two float types are compatible >> if they have the same mode, so it doesn't require the explicit conversions between >> these two types. I think it's exactly what we want. And to me, it looks unexpected >> to have two types with the same mode but different precision. >> >> So could we consider disabling the above workaround to make _Float128 have the same >> precision as __float128 (long double) (the underlying TFmode)? I tried the below >> change: > > The hacks with different precisions of powerpc 128-bit floating types are > very unfortunate, it is I assume because the middle-end asserted that scalar > floating point types with different modes have different precision. > We no longer assert that, as BFmode and HFmode (__bf16 and _Float16) have > the same 16-bit precision as well and e.g. C++ FE knows to treat standard > vs. extended floating point types vs. other unknown floating point types > differently in finding result type of binary operations or in which type > comparisons will be done. It's good news, for now those three long double modes on Power have different precisions, if they can have the same precision, I'd expect the ICE should be gone. > That said, we'd need some target hooks to > preserve the existing behavior with __float128/__ieee128 vs. __ibm128 > vs. _Float128 with both -mabi=ibmlongdouble and -mabi=ieeelongdouble. > > I bet the above workaround in generic code was added for a reason, it would > surprise me if _Float128 worked at all without that hack. OK, I'll have a look at those nan failures soon. > Shouldn't float128_type_node be adjusted instead the same way? Not sure, the regression testing only had nan related failures exposed. BR, Kewen