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 1BE7C3835E3B; Thu, 15 Dec 2022 07:54:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1BE7C3835E3B 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 (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BF7Fog0032333; Thu, 15 Dec 2022 07:54:17 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=XmMJ7o8udNhaYkcAH/7OCryul8zPxYQrcQq9rcUTJW4=; b=C2OqH5SKd9IWT3S8wiHj4UQxJ/5uV4Stw0d0UVNN20L5PFNyg60FD+XtSrCGM2dzhPw/ B0NsNGLna77GXeh1CPYxU6jdi7CS0pngt4aB/Ug373Q7fRKpBS/6OWvJx2W3lsNBCwJG TIVbDz3IoGu5PjtxKv9HSRNSlEG4gs5Sr+a615sIMuVI6gd1O2lPbB59HUZfKWtW6vOu eyNga9RGJT0sSxM1oQtvLhrQES9qgfZL5rVd5PoZg4aMfga16R8daLnl7zwwm6/hnq/Q lNXUlIdHECR4KPYZkPnDxw7OIXDuXVkFA9QQm2YW1DkN8ZvEKjkJkDb8KQLVDkCycP3A kw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mfy1s0tfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Dec 2022 07:54:17 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BF7kZOx027507; Thu, 15 Dec 2022 07:54:17 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 3mfy1s0teu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Dec 2022 07:54:16 +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 2BF3wrAu030269; Thu, 15 Dec 2022 07:54:14 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma04fra.de.ibm.com (PPS) with ESMTPS id 3mf0519xc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Dec 2022 07:54:14 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BF7sAji16909026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Dec 2022 07:54:10 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8BF562004F; Thu, 15 Dec 2022 07:54:10 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EFC4F20040; Thu, 15 Dec 2022 07:54:06 +0000 (GMT) Received: from [9.197.253.236] (unknown [9.197.253.236]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 15 Dec 2022 07:54:06 +0000 (GMT) Message-ID: <62a5ce3a-74e0-d8a2-d1e9-919a7183300d@linux.ibm.com> Date: Thu, 15 Dec 2022 15:54:05 +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: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299 Content-Language: en-US To: Jakub Jelinek Cc: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> <3cbaa3d2-4327-c62a-2904-eac5ca506d20@linux.ibm.com> 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: oduCy70g-wOiPaq2oWVTiHS-lw5gqu5G X-Proofpoint-ORIG-GUID: jl84-f-Z2pS0FvgtbVCqDAO3HaXAF6L7 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-15_03,2022-12-14_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 adultscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 mlxlogscore=593 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212150059 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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 2022/12/14 18:33, Jakub Jelinek wrote: > On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote: >>> The hacks with different precisions of powerpc 128-bit floating types are >>> very unfortunate, it is I assume because the middle-end asserted that scalar >>> floating point types with different modes have different precision. >>> We no longer assert that, as BFmode and HFmode (__bf16 and _Float16) have >>> the same 16-bit precision as well and e.g. C++ FE knows to treat standard >>> vs. extended floating point types vs. other unknown floating point types >>> differently in finding result type of binary operations or in which type >>> comparisons will be done. >> >> It's good news, for now those three long double modes on Power have different >> precisions, if they can have the same precision, I'd expect the ICE should be >> gone. > > I'm talking mainly about r13-3292, the asserts now check different modes > have different precision unless it is half vs. brain or vice versa, but > could be changed further, but if the precision is the same, the FEs > and the middle-end needs to know how to deal with those. > For C++23, say when __ibm128 is the same as long double and _Float128 is > supported, the 2 types are unordered (neither is a subset or superset of > the other because there are many _Float128 values one can't represent > in double double (whether anything with exponent larger than what double > can represent or most of the more precise values), but because of the > variable precision there are double double values that can't be represented > in _Float128 either) and so we can error on comparisons of those or on > arithmetics with such arguments (unless explicitly converted first). > But for backwards compatibility we can't do that for __float128 vs. __ibm128 > and so need to backwards compatibly decide what wins. And for the > middle-end say even for mode conversions decide what is widening and what is > narrowing even when they are unordered. Thanks for the pointer! I don't have good understanding on the backwards compatibility on those conversions, guessing Mike, Segher and David would have more insights. BR, Kewen