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 AF5203858CDA for ; Tue, 10 Jan 2023 03:22:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF5203858CDA 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 (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30A24kDm010584; Tue, 10 Jan 2023 03:21:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=UopVhKGLNB3Tyq6WLZNdQ1tpn50b5ZUzIYFdkUIIGuI=; b=qWbewRoLkVc9AnxhkIIRfW+JdFHpSTd/C16zQ1ZXUtnGixYKV8y0S0gPsL/f/2DJ94go cvTZ9AJ4AqHx0LoiwxI0nl2p2NCif+uBzVorqQEb5JSYxxNMRW/cDv+nqRlqDRcYsn76 sjO2W03WROwAvihVDj4FidP4sads4aDIOarGj4GVge3Sj0F9b8i97W/QFa7CH+QLeZDd A/fdpWZzNbfC1Jler3/Poa3MIs30u7gK/CSuNK1K73P3DKRFRx+DUVwioNmRgPik4HQB EfVNoW00+EBswTnQC/jrDl+J1lTWZxDdOAi6aXrEcAJhuVVohGWln2mbSbASJvsmTGhG xg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n0swwg2v7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Jan 2023 03:21:59 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30A2uiP2030795; Tue, 10 Jan 2023 03:21:58 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n0swwg2ux-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Jan 2023 03:21:58 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30A0Ulp1008553; Tue, 10 Jan 2023 03:21:57 GMT Received: from smtprelay01.wdc07v.mail.ibm.com ([9.208.129.119]) by ppma04dal.us.ibm.com (PPS) with ESMTPS id 3my0c7k8th-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Jan 2023 03:21:57 +0000 Received: from smtpav06.wdc07v.mail.ibm.com (smtpav06.wdc07v.mail.ibm.com [10.39.53.233]) by smtprelay01.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30A3LteZ41746930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jan 2023 03:21:55 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F9F458054; Tue, 10 Jan 2023 03:21:55 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8AEBD5803F; Tue, 10 Jan 2023 03:21:54 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Tue, 10 Jan 2023 03:21:54 +0000 (GMT) Date: Mon, 9 Jan 2023 22:21:52 -0500 From: Michael Meissner To: Michael Meissner , Joseph Myers , Segher Boessenkool , "Kewen.Lin" , GCC Patches , 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: iIo_90Wu91tnFfrFRB__gSA7SskOrsu3 X-Proofpoint-GUID: x2HpOu6deMsB4kTZFPBCxi969XXwQtyI 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-09_16,2023-01-09_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301100018 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_MANYTO,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Fri, Jan 06, 2023 at 07:41:07PM -0500, Michael Meissner wrote: > 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. > > I spent a few days on working on this. I have patches to make the 3 128-bit > types to all have TYPE_PRECISION of 128. To do this, I added a new mode macro > (FRACTIONAL_FLOAT_MODE_NO_WIDEN) that takes the same arguments as > FRACTIONAL_FLOAT_MODE. ... I had the patches to change the precision to 128, and I just ran them. C and C++ do not seem to be bothered by changing the precision to 128 (once I got it to build, etc.). But Fortran on the other hand does actually use the precision to differentiate between IBM extended double and IEEE 128-bit. In particular, the following 3 tests fail when long double is IBM extended double: gfortran.dg/PR100914.f90 gfortran.dg/c-interop/typecodes-array-float128.f90 gfortran.dg/c-interop/typecodes-scalar-float128.f90 I tried adding code to use the old precisions for Fortran, but not for C/C++, but it didn't seem to work. So while it might be possible to use a single 128 for the precision, it needs more work and attention, particularly on the Fortran side. I'm not sure it is worth it to try and change things. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com