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 12BA43858D20 for ; Tue, 3 Jan 2023 23:27:17 +0000 (GMT) Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 303KSprg037189; Tue, 3 Jan 2023 23:27:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=01xysbznZ6yIQPQhw9H1JLn5kF+E21CkptoE/Faf7kU=; b=V/qNC5abI7cu5O0NrIamc8OGJIBQDyukTioYX/YIU3328dsZF5hvOIVkbClChaczwQYK 4N23bsGiKNSiwv4MA5fO2+aX3CDNXuxgukyzEPoEmsDOa71Z46GJtDPVjW5102QRe0NF mI6Ms26hBkebRFcNlB+BX6L7ugSBMfs7gzv28nzZB3/8STsZqNCBp//YPdYhRLJmtusX 5U134NPBeuHtJ02PoC15IPQVFrbWMydJnMS5AzXQ2klPquIBY2BBjN4dr7DgiKnQqOXm qIqptqB8XoX7qnWyN507LoBBSzrf6brDd+yxbFvzBIMJkN2eOxNb65L+6xZnliGDk0X+ Ug== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mvhq89suh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2023 23:27:12 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 303N9PQ9032093; Tue, 3 Jan 2023 23:27:11 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mvhq89su6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2023 23:27:11 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 303MeabI030437; Tue, 3 Jan 2023 23:27:10 GMT Received: from smtprelay07.wdc07v.mail.ibm.com ([9.208.129.116]) by ppma03dal.us.ibm.com (PPS) with ESMTPS id 3mtcq7hm9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2023 23:27:10 +0000 Received: from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com [10.39.53.230]) by smtprelay07.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 303NR8Fe8192758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Jan 2023 23:27:08 GMT Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C7A665805F; Tue, 3 Jan 2023 23:27:08 +0000 (GMT) Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B907458058; Tue, 3 Jan 2023 23:27:07 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Tue, 3 Jan 2023 23:27:07 +0000 (GMT) Date: Tue, 3 Jan 2023 18:27:06 -0500 From: Michael Meissner To: Joseph Myers Cc: Segher Boessenkool , "Kewen.Lin" , GCC Patches , Michael Meissner , David Edelsohn , Jakub Jelinek , Peter Bergner , Richard Biener , Richard Sandiford Subject: Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299] Message-ID: Mail-Followup-To: Michael Meissner , Joseph Myers , Segher Boessenkool , "Kewen.Lin" , GCC Patches , David Edelsohn , Jakub Jelinek , Peter Bergner , Richard Biener , Richard Sandiford References: <718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com> <20221221212407.GU25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: PY2kHkIyOanaDMqXxN6btZS0qGPTo3YO X-Proofpoint-GUID: Q7IWsjiTGS42-rThC-KEJAQAqsNWL0QW 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=2023-01-03_07,2023-01-03_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 malwarescore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 clxscore=1011 bulkscore=0 mlxlogscore=999 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301030194 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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 Wed, Dec 21, 2022 at 09:40:24PM +0000, 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). > > 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. > > How the TYPE_PRECISION compares to that of __ibm128, or of long double > when that's double-double, is less important. When I did the original implementation years ago, there were various implicit assumptions that for any one precision, there must be only one floating point type. I tend to agree that logically the precision should be 128, but until we go through and fix all of these assumptions, it may be problematical. This shows up in the whole infrastructure of looking for a FP type with larger precision than a given precision. There just isn't an ordering that works and preserves all values. I'm coming to think that we may want 2 types of FP, one is a standard FP type where you can convert to a larger type, and the other for various FP types where there is no default widening conversion. And logically there is the issue with 16-bit floats, giving we have different versions of 16-bit float. And if an implementation ever wanted to support both BID and DFP decimal types at the same time, they would have similar issues. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com