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 6F6413858D1E for ; Thu, 22 Dec 2022 06:40:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F6413858D1E 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 2BM6Diaf013271; Thu, 22 Dec 2022 06:39:58 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=UoXNBSNDAG5TC2Tdk76Dpt6X74ULWrofsumWTdi9uQ0=; b=bJiDZW0IFDC40trtNRkuGCmxraGdbhVdCeMrr6bN/QxS7sPZQylzypFhmR/NVDjDG6aj 2xIcwWmwGeaU9Xa7V9dtH379SB4mFe+cgHziEVJ9pxPMe116CrCnDUoO+bcJUUQ9HoHe PC+JReVpFuz9CFD/PEek9qU3qlEnK+kuW2pTck78ak/++XrMX3xudZ8pu42l6SIt29Qx dOts1mx6Hx+JHuPuWq/zI35wyfXbkiqhyUUNkJfruQV5FU8rZj+/phIOjls9xBWUnfpA uH4xUuqpAqjN6ffhGhu4eBdXiSfkYG1txwOcOUllttCHskL4dqIKXD/je407W6mLN7oU mw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mmhsgh52f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Dec 2022 06:39:54 +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 2BM6PK5P021744; Thu, 22 Dec 2022 06:39:01 GMT Received: from ppma05fra.de.ibm.com (6c.4a.5195.ip4.static.sl-reverse.com [149.81.74.108]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mmhsgh1te-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Dec 2022 06:39:00 +0000 Received: from pps.filterd (ppma05fra.de.ibm.com [127.0.0.1]) by ppma05fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BM1eN5T004206; Thu, 22 Dec 2022 06:37:11 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma05fra.de.ibm.com (PPS) with ESMTPS id 3mh6yy4rtu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Dec 2022 06:37:11 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BM6b7im43450768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Dec 2022 06:37:07 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 74FE420049; Thu, 22 Dec 2022 06:37:07 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0206E20040; Thu, 22 Dec 2022 06:37:04 +0000 (GMT) Received: from [9.200.41.171] (unknown [9.200.41.171]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 22 Dec 2022 06:37:03 +0000 (GMT) Message-ID: Date: Thu, 22 Dec 2022 14:37:02 +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: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299] Content-Language: en-US To: Joseph Myers Cc: GCC Patches , Michael Meissner , David Edelsohn , Jakub Jelinek , Peter Bergner , Richard Biener , Richard Sandiford , Segher Boessenkool References: <718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com> <20221221212407.GU25951@gate.crashing.org> 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: zcLwgWZYM409T99cx_7-hXwpRtbk39Mc X-Proofpoint-ORIG-GUID: JoOlY24c0f5xg2_DVDPneTc8_KDzM0U4 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-22_01,2022-12-21_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 bulkscore=0 spamscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 clxscore=1015 mlxscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212220057 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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: Hi Joseph, on 2022/12/22 05:40, Joseph Myers wrote: > On Wed, 21 Dec 2022, Segher Boessenkool wrote: > >>> --- 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. */ >> >> It has precision 126 now fwiw. >> >> Joseph: what do you think about this patch? Is the workaround it >> removes still useful in any way, do we need to do that some other way if >> we remove this? > > I think it's best for the TYPE_PRECISION, for any type with the binary128 > format, to be 128 (not 126). I agree that it's more reasonable to use 128 for it (all of them) eventually, but what I thought is that if we can get rid of this workaround first to make the bootstrapping survive. Commit r9-1302-g6a8886e45f7eb6 makes TFmode/ KFmode/IFmode have different precisions with some reasons, Jakub mentioned commit r13-3292, I think later we can refer to it and have a try to unique those modes to have the same precisions (probably next stage1), I guess Mike may have more insightful comments here. > > It's necessary that _Float128, _Float64x and long double all have the same > TYPE_PRECISION when they have the same (binary128) format, or at least > that TYPE_PRECISION for _Float128 >= that for long double >= that for > _Float64x, so that the rules in c_common_type apply properly. > a. _Float128, _Float64x and long double all have the same TYPE_PRECISION when they have the same (binary128) format. b. TYPE_PRECISION for _Float128 >= that for long double >= that for _Float64x. **Without this patch**, 1) -mabi=ieeelongdouble (these three are ieee128) _Float128 => 128 ("type => its TYPE_PRECISION") _Float64x => 128 long double => 127 // Neither a and b holds. 2) -mabi=ibmlongdouble (long double is ibm128) _Float128 => 128 _Float64x => 128 long double => 127 // a N/A, b doesn't hold. **With this patch**, 1) -mabi=ieeelongdouble _Float128 => 127 _Float64x => 127 long double => 127 // both a and b hold. 2) -mabi=ibmlongdouble _Float128 => 126 _Float64x => 126 long double => 127 // a N/A, b doesn't hold. IMHO, this patch improves the status quo slightly. BR, Kewen