From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 83CAF3858D32; Thu, 6 Apr 2023 06:17:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 83CAF3858D32 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 (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3362tTK8007323; Thu, 6 Apr 2023 06:17:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=Xj6WMtIpOeg5tnKI530+c/fOtYYDbqUfRHWK4Ctv7TY=; b=NDYu+rnSOG0KxKz8AuJOpXJ/nEgnW0GYaFrqUhjx9xsA1Tr9uCy7vd+6AyEvRfgfg9b5 7t6PPDKv3KC/WRZcBaRJcu/gjtuNoPnHLRuksXXBI6R39rTGN6zS6TPKrmlm9ympOWTe tspXV02xn08mhw2UBKlJkeEV5JWbKNFa6/Gy0qA3EnuIEpNdme5eROKbg/aJRwRBwl6L YhJpCZIKUFeYnVAGvnmfvrJim0MNg6b2ZW9dCof/zv2zAiSwsJZzMBhPq8zLxHA8Gfr+ EL5tO2tPJOReKAPKDvLmlJZ7LaPTS+qkQXEnuTEulCS5ILDcF8uy8baPEH/kDDhAz1mg 3Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ps9935h1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2023 06:17:11 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33662pSZ000616; Thu, 6 Apr 2023 06:17:11 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ps9935h0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2023 06:17:11 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3361vZOR027980; Thu, 6 Apr 2023 06:17:09 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma03ams.nl.ibm.com (PPS) with ESMTPS id 3ppc87405q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2023 06:17:09 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3366H6t321234314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Apr 2023 06:17:06 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2625A20040; Thu, 6 Apr 2023 06:17:04 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0ED2520049; Thu, 6 Apr 2023 06:17:02 +0000 (GMT) Received: from [9.43.168.53] (unknown [9.43.168.53]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 6 Apr 2023 06:17:01 +0000 (GMT) Message-ID: <9eb5b41f-8ab1-ef2e-0429-8ce335e18304@linux.ibm.com> Date: Thu, 6 Apr 2023 14:17:00 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] [PR99708] [rs6000] don't expect __ibm128 with 64-bit long double Content-Language: en-US To: Alexandre Oliva Cc: Rainer Orth , Mike Stump , David Edelsohn , Segher Boessenkool , Kewen Lin , gcc-patches@gcc.gnu.org References: <8e75ef66-c654-155e-ccf6-ac95cc38c740@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 8jMAFjf8jGrVJOXrt9QIQxcoupmv2Ea5 X-Proofpoint-ORIG-GUID: ZHGzCv0ZgJVPOqbymqX8ZUUJV_WXm19Z Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-06_02,2023-04-05_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxlogscore=859 spamscore=0 priorityscore=1501 impostorscore=0 clxscore=1015 phishscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304060052 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,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 Alexandre, on 2023/4/6 12:43, Alexandre Oliva wrote: > Hello, Kewen, > > Thanks for the feedback. > > On Mar 27, 2023, "Kewen.Lin" wrote: > >> on 2023/3/25 16:37, Alexandre Oliva via Gcc-patches wrote: >>> >>> When long double is 64-bit wide, as on vxworks, the rs6000 backend >>> defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but >>> pr99708.c expected both to be always defined. Adjust the test to >>> match the implementation. > >> There is one patch from Mike to define type __ibm128 even without >> IEEE 128-bit floating point support, it's at the link: > >> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599984.html > >> I would expect this issue would be gone if the adjustment on the >> support of type __ibm128 gets landed in future. > > Yeah, the issue would then be gone, but the patch is compatible with > that proposed change: if __ibm128 and the corresponding SIZEOF macro are > defined, the proposed change is a no-op. Yeah, I agree. > >> So maybe we can just xfail this for longdouble64? What do you >> think? > > I wouldn't object to that, and I could even write and test the alternate > patch for that, but I fail to understand why that would be more > desirable. Would you be so kind as to enlighten me? The reason why personally I preferred to fix it with xfail is that: 1) if the mentioned patch changing the condition of defining __ibm128 type gets re-tested, this case would change from XFAIL to XPASS, then it gets our attentions and shows some benefit of that patch (it can be also mentioned in that commit log). 2) once the mentioned patch gets landed, the below hunk in the proposed patch becomes unreachable: +#else + || __SIZEOF_LONG_DOUBLE__ * __CHAR_BIT__ != 64 +#endif And it's very likely we won't remember to remove it. At that time when someone reads the code, he/she can probably get the impression that type __ibm128 is not always defined even under effective target ppc_float128_sw, it could cause some misunderstanding. Does it make sense to you? BR, Kewen