From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 7FDED3858D1E for ; Wed, 21 Dec 2022 09:25:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FDED3858D1E 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 (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BL9FBd2021020; Wed, 21 Dec 2022 09:24:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : to : cc : from : subject : content-type : content-transfer-encoding : mime-version; s=pp1; bh=X0fyTaMIvJk8hs0kcz7/CsAae7bhrXoZUW0nqWatJtE=; b=hhMVH0w/3H7lpsLB7NVGVg8STeZRv+4BxVKR0fHpXwnwOlzzpsW+C2WzMoE21gt3UGgI gvd5WxPNqG9HajEpecuQsj+zxSoxul/yfoMOLEYoopG+4KzQpqzIUVq1/RU+/lv9pu9a qrMSiIRLc2c7CmaKfInMS6FGToGyKo9zsa/rBlKJFGokk8XLJUzkKZcis0lylWLtgeZI NE6uB1YqpkKVYQgNNFtRBFDWXGunVpVUFHE9ckw6Sr8fWw6GjTLDGxVY2vkdTxAnkS/M +tv9nMgW+wACId1nv/t3q3YlrdG3k0/fyEMMq734A+XX5tCX2BerNWs3U8DVJYgybV7Q Eg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mkybkg7j2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Dec 2022 09:24:55 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BL9FMx3021464; Wed, 21 Dec 2022 09:24:54 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mkybkg7dn-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Dec 2022 09:24:54 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BKNC9Is027900; Wed, 21 Dec 2022 09:02:26 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma04fra.de.ibm.com (PPS) with ESMTPS id 3mh6yw3tff-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Dec 2022 09:02:26 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BL92MLA49348880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Dec 2022 09:02:22 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3B9FE20049; Wed, 21 Dec 2022 09:02:22 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1C7CB20043; Wed, 21 Dec 2022 09:02:19 +0000 (GMT) Received: from [9.197.239.17] (unknown [9.197.239.17]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 21 Dec 2022 09:02:18 +0000 (GMT) Message-ID: <718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com> Date: Wed, 21 Dec 2022 17:02:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: GCC Patches Cc: Michael Meissner , Segher Boessenkool , David Edelsohn , Jakub Jelinek , Joseph Myers , Peter Bergner , Richard Biener , Richard Sandiford From: "Kewen.Lin" Subject: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299] Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: o0H8O6x8vg7ggTmBqHbBMdbFlv3uw0Zg X-Proofpoint-GUID: IpptQucEYREDdOXEZYWBbowVoLwTp_r1 Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 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-21_04,2022-12-20_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212210072 X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,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: Hi, This a different attempt from Mike's approach[1][2] to fix the issue in PR107299. With option -mabi=ieeelongdouble specified, type long double (and __float128) and _Float128 have the same mode TFmode, but they have different type precisions, it causes the assertion to fail in function fold_using_range::fold_stmt. IMHO, it's not sensible that two types have the same mode but different precisions. By tracing where we make type _Float128 have different precision from the precision of its mode, I found it's from a work around for rs6000 KFmode. Being curious why we need this work around, I disabled it and tested it with some combinations as below, but all were bootstrapped and no regression failures were observed. - BE Power8 with --with-long-double-format=ibm - LE Power9 with --with-long-double-format=ibm - LE Power10 with --with-long-double-format=ibm - x86_64-redhat-linux - aarch64-linux-gnu For LE Power10 with --with-long-double-format=ieee, since it suffered the bootstrapping issue, I compared the regression testing results with the one from Mike's approach. The comparison result showed this approach can have several more test cases pass and no cases regressed, they are: 1) libstdc++: 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) Caused by the same reason: one static assertion fail in header file format (_Type is __ieee128): static_assert(__format::__formattable_with<_Type, _Context>); 2) gfortran: NA->PASS: gfortran.dg/c-interop/typecodes-array-float128.f90 NA->PASS: gfortran.dg/c-interop/typecodes-scalar-float128.f90 NA->PASS: gfortran.dg/PR100914.f90 Due to that the effective target `fortran_real_c_float128` checking fails, fail to compile below source with error msg: "Error: Kind -4 not supported for type REAL". use iso_c_binding real(kind=c_float128) :: x x = cos (x) end 3) g++: FAIL->PASS: g++.dg/cpp23/ext-floating1.C -std=gnu++23 Due to the static assertion failing: static_assert (is_same::value); * compatible with long double This approach keeps type long double compatible with _Float128 (at -mabi=ieeelongdouble) as before, so for the simple case like: _Float128 foo (long double t) { return t; } there is no conversion. See the difference at optimized dumping: with the contrastive approach: _Float128 foo (long double a) { _Float128 _2; [local count: 1073741824]: _2 = (_Float128) a_1(D); return _2; } with this: _Float128 foo (long double a) { [local count: 1073741824]: return a_1(D); } IMHO, it's still good to keep _Float128 and __float128 compatible with long double, to get rid of those useless type conversions. Besides, this approach still takes TFmode attribute type as type long double, while the contrastive approach takes TFmode attribute type as type _Float128, whose corresponding mode isn't TFmode, the inconsistence seems not good. As above, I wonder if we can consider this approach which makes type _Float128 have the same precision as MODE_PRECISION of its mode, it keeps the previous implementation to make type long double compatible with _Float128. Since the REAL_MODE_FORMAT of the mode still holds the information, even if some place which isn't covered in the above testing need the actual precision, we can still retrieve the actual precision with that. Any thoughts? [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604834.html [2] v3 https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608513.html BR, Kewen ----- PR target/107299 gcc/ChangeLog: * tree.cc (build_common_tree_nodes): Remove workaround for rs6000 KFmode. --- gcc/tree.cc | 9 --------- 1 file changed, 9 deletions(-) diff --git a/gcc/tree.cc b/gcc/tree.cc index 254b2373dcf..cbae14d095e 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char) if (!targetm.floatn_mode (n, extended).exists (&mode)) continue; int precision = GET_MODE_PRECISION (mode); - /* 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; FLOATN_NX_TYPE_NODE (i) = make_node (REAL_TYPE); TYPE_PRECISION (FLOATN_NX_TYPE_NODE (i)) = precision; layout_type (FLOATN_NX_TYPE_NODE (i)); -- 2.27.0