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 677763833E8D; Wed, 14 Dec 2022 08:46:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 677763833E8D 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 (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BE7ktkf003060; Wed, 14 Dec 2022 08:46:19 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=uQyY8Mv2lx8jv4VWhfnyU2b4N8glpnL6T4/8qa2DX7M=; b=eUjwX1jNkzQ4bULS7OSirDczveAVmpGVdK6rOUwuNF2iNwRJbLHy9+CmV/dShQLk5PV7 o7Ce2/8sZC3RR9oo39x2EgUno60tkJ9H4sVoiFghp2dmSms8JqIG4mf11Gp6uxd8ZhCX RttapG+PzHvRZOlvcQsDOaaqrErZmh0u8TvyhYUAUhU3XLepOEsZJo5S/xHSFk5RH9Hy AWNfcZ2gVip/mkinl2hQDZKralQH0mugnfsJZS2eppkcwGvJ2jrF9nA2f/RtRVxKbqQn UkfsM427u59pnYquZ7EyqkkJCWGUx+BT3ChWlgTQDSFKbmsO2Y2bkHbl19HfmszIKZ1D 7w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfadaseqr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 08:46:18 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BE7qJW1022215; Wed, 14 Dec 2022 08:46:18 GMT Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfadasepy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 08:46:18 +0000 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BDK2wbs026041; Wed, 14 Dec 2022 08:46:16 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma03fra.de.ibm.com (PPS) with ESMTPS id 3mf0380he3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 08:46:16 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BE8kCM041812254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Dec 2022 08:46:12 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5EFA620049; Wed, 14 Dec 2022 08:46:12 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8E6AA20040; Wed, 14 Dec 2022 08:46:09 +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 08:46:09 +0000 (GMT) Message-ID: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> Date: Wed, 14 Dec 2022 16:46:07 +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: Michael Meissner Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool , Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers References: From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Rc70WqGVyaokEnThlqb-bk_cjVy02CGS X-Proofpoint-GUID: KR8Ctq9LfBXlQYZAqWd25L_yt3BO-Y5S 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_03,2022-12-13_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 impostorscore=0 adultscore=0 malwarescore=0 clxscore=1015 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212140066 X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,KAM_SHORT,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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: diff --git a/gcc/tree.cc b/gcc/tree.cc index 254b2373dcf..10fcb3d88ca 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -9442,6 +9442,7 @@ build_common_tree_nodes (bool signed_char) if (!targetm.floatn_mode (n, extended).exists (&mode)) continue; int precision = GET_MODE_PRECISION (mode); +#if 0 /* Work around the rs6000 KFmode having precision 113 not 128. */ const struct real_format *fmt = REAL_MODE_FORMAT (mode); @@ -9451,6 +9452,7 @@ build_common_tree_nodes (bool signed_char) gcc_assert (min_precision == n); if (precision < min_precision) precision = min_precision; +#endif FLOATN_NX_TYPE_NODE (i) = make_node (REAL_TYPE); TYPE_PRECISION (FLOATN_NX_TYPE_NODE (i)) = precision; layout_type (FLOATN_NX_TYPE_NODE (i)); It can be bootstrapped (fixing the ICE in PR107299). Comparing with the baseline regression test results with patch #1, #2 and #3, I got some positive: FAIL->PASS: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors) FAIL->PASS: 17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors) FAIL->PASS: 17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors) FAIL->PASS: 17_intro/headers/c++2020/all_pedantic_errors.cc (test for excess errors) FAIL->PASS: 17_intro/headers/c++2020/operator_names.cc (test for excess errors) FAIL->PASS: 17_intro/headers/c++2020/stdc++.cc (test for excess errors) FAIL->PASS: 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess errors) FAIL->PASS: std/format/arguments/args.cc (test for excess errors) FAIL->PASS: std/format/error.cc (test for excess errors) FAIL->PASS: std/format/formatter/requirements.cc (test for excess errors) FAIL->PASS: std/format/functions/format.cc (test for excess errors) FAIL->PASS: std/format/functions/format_to_n.cc (test for excess errors) FAIL->PASS: std/format/functions/size.cc (test for excess errors) FAIL->PASS: std/format/functions/vformat_to.cc (test for excess errors) FAIL->PASS: std/format/parse_ctx.cc (test for excess errors) FAIL->PASS: std/format/string.cc (test for excess errors) FAIL->PASS: std/format/string_neg.cc (test for excess errors) FAIL->PASS: g++.dg/cpp23/ext-floating1.C -std=gnu++23 (test for excess errors) and some negative: PASS->FAIL: gcc.dg/torture/float128-nan.c -O0 execution test PASS->FAIL: gcc.dg/torture/float128-nan.c -O1 execution test PASS->FAIL: gcc.dg/torture/float128-nan.c -O2 execution test PASS->FAIL: gcc.dg/torture/float128-nan.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test PASS->FAIL: gcc.dg/torture/float128-nan.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test PASS->FAIL: gcc.dg/torture/float128-nan.c -O3 -g execution test PASS->FAIL: gcc.dg/torture/float128-nan.c -Os execution test PASS->FAIL: gcc.target/powerpc/nan128-1.c execution test The negative part is about nan, I haven't looked into it, but I think it may be the reason why we need the workaround there, CC Joseph. Anyway it needs more investigation here, but IMHO the required information (ie. the actual precision) can be retrieved from REAL_MODE_FORMAT(mode) of TYPE_MODE, so it should be doable to fix some other places. Some concerns on the way of patch #2 are: 1) long double is with TFmode, it's not taken as compatible with _Float128 even if -mabi=ieeelongdouble specified, we can have inefficient IRs than before. 2) we make type attribute with TFmode _Float128 (KFmode), but there is one actual type long double with TFmode, they are actually off. Comparing with patch #2, this way to remove the workaround in build_common_tree_nodes can still keep the things as before. It may be something we can consider here. BR, Kewen