From patchwork Wed Dec 21 09:02:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 35305 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp3424166wrn; Wed, 21 Dec 2022 01:25:56 -0800 (PST) X-Google-Smtp-Source: AMrXdXsJuj9mW4Z40zuao1UUHBKnopUKed1mtIQwrQQL7nL4wu8okv4FxO1uDpZ9eJnsYZ5+Wd4X X-Received: by 2002:a05:6402:538f:b0:45c:835c:1ebb with SMTP id ew15-20020a056402538f00b0045c835c1ebbmr5423979edb.9.1671614756417; Wed, 21 Dec 2022 01:25:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671614756; cv=none; d=google.com; s=arc-20160816; b=RPDSi3e+3eoGIyxoZhyUBeLqVzVPYDBObCfBQnbHLOdhjtgyQ28fxQmDsZ2zg7E4i4 WdBBmUeF34xsDJe/cR4iDaqKZgSySkMF3avgPg5BiL64kYWbTzzQ22KKZgJVijb+Eywq Qw4clGZ5R55X9ds/+Ct+JcmnMomYimReyNfEkfuy5WuW16BmsS3nickd8l0G6ttdGe9a 4Hi3zZcPB+JeKXOMlX6mnKa5Bzu231VqajnVaTAxiL8Es7dUdxoaRHG+9GZfOPfGCwSx PPsMoXFbQQmOhh6jXZ5KNgpb3Lu1MW07wg00UNcrdiTzDmcQ7aWZlaORsbJHNd+rtbig 3Myw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:mime-version :content-transfer-encoding:subject:cc:to:content-language:user-agent :date:message-id:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=X0fyTaMIvJk8hs0kcz7/CsAae7bhrXoZUW0nqWatJtE=; b=P4LheYwlB6MTarfbyvRqjZ/W38901qPvvdYEve1ua4Ja1jTpDi70ZiRpYMpNYUW89y L0y0dsdGQVtiItb2N9mUk1sYbywQgoDxbkz/Eii8e8QF/JQTBeDrTACnKsOLz77cD+De qKtmAp5EMgr+Usb6urwRkhOYTrSS11HIZ26BJdUZBehcp0JFS9JAztmt7o9l1heenb0m DSoFi21itHOkuHR6TEoyLK3+hkAbAnmWlUiHL8cmwpR5w0I7mdcie3UcXuI2W+YXqhAv 2azyEcl/Vxs8JLFnxnUCA8PfO6GifER+X8JxawXQWehxw+If8RWucy0CMiDuaqMWjCc+ K9wA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=nD1Z3Klo; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id t22-20020a056402525600b00469cdb77fe2si4745567edd.83.2022.12.21.01.25.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Dec 2022 01:25:56 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=nD1Z3Klo; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 32ECF385703F for ; Wed, 21 Dec 2022 09:25:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 32ECF385703F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671614755; bh=X0fyTaMIvJk8hs0kcz7/CsAae7bhrXoZUW0nqWatJtE=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=nD1Z3Klo5LWFhkgQ7pQieV4fWdNbSbtbsZAtltnvzRf5A5SyQdHDwTrIkNmw6r/yE v+WH8j+CIXZK4mPIYPzbFO3dgpGzfYWywt5dFjmXKHWySwQpBwoEwRlwy+s76JX5B/ XoDJRzNqIePypQmWF4BXRZ4buoMXxetQ15WZQAIw= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 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 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 Subject: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299] X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: o0H8O6x8vg7ggTmBqHbBMdbFlv3uw0Zg X-Proofpoint-GUID: IpptQucEYREDdOXEZYWBbowVoLwTp_r1 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: "Kewen.Lin via Gcc-patches" From: "Kewen.Lin" Reply-To: "Kewen.Lin" Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752815114934459127?= X-GMAIL-MSGID: =?utf-8?q?1752815114934459127?= 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(-) -- 2.27.0 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));