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 38F2B3858D1E for ; Thu, 22 Dec 2022 06:24:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 38F2B3858D1E 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 (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BM5hYbJ030465; Thu, 22 Dec 2022 06:24:45 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=peOjBoGABxBHBxaGkLyz3icgeQ3zZWjYHPLbdS1LeCc=; b=Xm6cdGYtTnuKjn14fJKRGpOsai5tvtdMm60mmILO/N/EzgnVAlUrHKxUsG0juf3lOo8c GSN8ieFNOo/kEsQ4LMjFUqYtJNWQnfD15if0L6dUdwzhqWuaFElXo0w8eX/bMsERCFK0 sC13o0Oh5WuqccjpgqndWUhtRN0kiTUmEvOSDxfVe0iPQtJwfRjffMbqQLdpeMrbHiTT hmgPqs4Nwwu78IEEkNwuYPTu31rUAIn692PDfI23uN3LTdqU8b8Xnx+wGLHAYOHbSU87 4xR7sCOXB4bmZf69wOIHKDPIOJENpn9+R0LaYTX+VzuOaLHT4r7CwhX2OxiuTcHvmgmD 0g== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mmhbc9e77-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Dec 2022 06:24:45 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BM6MEFR000338; Thu, 22 Dec 2022 06:24:45 GMT Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3mmhbc9e6u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Dec 2022 06:24:45 +0000 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BM1mJFi006628; Thu, 22 Dec 2022 06:07:50 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma06fra.de.ibm.com (PPS) with ESMTPS id 3mh6yxmrtr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Dec 2022 06:07:50 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BM67k6I42402060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Dec 2022 06:07:46 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5929A20040; Thu, 22 Dec 2022 06:07:46 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C331620049; Thu, 22 Dec 2022 06:07:42 +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:07:42 +0000 (GMT) Message-ID: <9f41bd91-85b3-e5a6-1774-ecfd8a6be15c@linux.ibm.com> Date: Thu, 22 Dec 2022 14:07:40 +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: Segher Boessenkool Cc: GCC Patches , Michael Meissner , David Edelsohn , Jakub Jelinek , Joseph Myers , Peter Bergner , Richard Biener , Richard Sandiford References: <718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com> <20221221212407.GU25951@gate.crashing.org> From: "Kewen.Lin" In-Reply-To: <20221221212407.GU25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: ETX0-xNGEpp19pP1SVJiL8MJ03bZ7MuY X-Proofpoint-GUID: wAZHjLh3nxCuYr0qdKrngDSZju1Bekm0 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 lowpriorityscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 impostorscore=0 malwarescore=0 phishscore=0 suspectscore=0 adultscore=0 clxscore=1015 spamscore=0 mlxlogscore=804 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212220052 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 Segher, on 2022/12/22 05:24, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 21, 2022 at 05:02:17PM +0800, Kewen.Lin wrote: >> This a different attempt from Mike's approach[1][2] to fix the >> issue in PR107299. > > Ke Wen, Mike: so iiuc with this patch applied all three of Mike's > patches are unnecessary? I think the 1st patch is still needed, it's to fix a latent issue as the associated test cases {mul,div}ic3-1.c show. > Does it fix the new testcases in Mike's series as well? Yeah, it doesn't suffer the issue exposed by float128-hw4.c, so it doesn't need that adjustment on float128-hw4.c. It can also make newly added float128-hw{12,13}.c pass. >> 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. > > "Precision" does not have a useful meaning for all floating point > formats. It does not have one for double-double for example. The way > precision is defined in IEEE FP means double-double has 2048 bits of > precision (or is it 2047), not useful. Taking the precision of the > format instead to be the minimum over all values in that format gives > double-double the same precision as IEEE DP, not useful in any practical > way either :-/ OK, I think that's why we don't see any regressions with this work around removal, :) > >> --- 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. Yes, with -mabi=ibmlongdouble, it uses KFmode so 126, while with -mabi=ieeelongdouble, it uses TFmode so 127. BR, Kewen