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 6BAF23858D1E for ; Wed, 8 May 2024 05:33:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BAF23858D1E 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6BAF23858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715146387; cv=none; b=i/ARRkwtXGN9eZIihLiX43WumaxqU/37iBd5iXe8Uq8eadmTYsyMg0JOy7ITpsP5EPx0PpzKaqPDhaEj8LsGQDMrHylfLHeWYKr1ZqWouRWw1FF9hCCLFIzdU7Q78hxIf6E5U//puAlXKBJm8xUgjVXV2EpVMFdj17zFPJxFHc8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715146387; c=relaxed/simple; bh=u0NozMILcYn1FuZppE0tKseR9R4Xvy0HRz+2XcAC8mg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=QNiZT3Gsz9XXISa4YOli+Wo9BDuaV8GZzyo17WXCIdWkPfXaFjIX7sdOgPwgHRBwCAA3FTFtfy1YJ8+esXWXNg/Xd4i5dnuE5Kfx1Uz4oB7FswS7nvfzYwobaHLdhcjIc0Ode+mBK+qfXQxZ3s360MWgsvoQUd0eJiOyxYleNLg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353727.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 4485WpVL019776; Wed, 8 May 2024 05:33:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : from : to : cc : references : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=7mZJ7K6PsmKQ0k/6cJrfWYWwdlrywDDUxhkFNsW3bac=; b=q44UHp800R5K42P4jLlP7/aaOpc79JYyw3QJxS1q3pB5+7DBDlfKzoOnkE194YjTiMFW eQS3hbzd8pBeV/lQesenJr1Gmt7y/pbkJFX8/FvAMApmshPiiF83ucVAjNkxmcjiBjwJ 6GPDq5rYeXSmsuZFWn0uWeloDZ7Ewa3tZ/zXkgvZUiXK0iDVJvBu8zVv6g5HS0FSTrVB bfN7qRHvmrbnFNKR1OQURXHDqyKRomIkc+EAfcQFgHH/UjwoYrBv0HjX4JnWrUann34h +nmmZRzv/Ui2VA4AIqucWO56A7N7kn67FsNr8x5K+mYrAy23apBA9bO/v9TWJhwg1hbV zw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3y03b0001s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 May 2024 05:33:04 +0000 Received: from m0353727.ppops.net (m0353727.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4485X3OG020574; Wed, 8 May 2024 05:33:03 GMT Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3y03b0001p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 May 2024 05:33:03 +0000 Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 4484ULvm004174; Wed, 8 May 2024 05:33:02 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3xysgsavw0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 May 2024 05:33:02 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4485WuTI47251738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 May 2024 05:32:58 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8EC9820049; Wed, 8 May 2024 05:32:56 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AE21520040; Wed, 8 May 2024 05:32:53 +0000 (GMT) Received: from [9.200.57.36] (unknown [9.200.57.36]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 8 May 2024 05:32:53 +0000 (GMT) Message-ID: <79b24bb3-f5b7-5ada-ca84-a1deda04df83@linux.ibm.com> Date: Wed, 8 May 2024 13:32:52 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: [PATCH 3/4] ranger: Revert the workaround introduced in PR112788 [PR112993] Content-Language: en-US From: "Kewen.Lin" To: GCC Patches Cc: Jakub Jelinek , Segher Boessenkool , Peter Bergner , Michael Meissner , David Edelsohn , Andrew MacLeod , "hernandez, aldy" References: <813e8433-0428-1854-c82c-fc0743368fa8@linux.ibm.com> In-Reply-To: <813e8433-0428-1854-c82c-fc0743368fa8@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 6jdq54MzjiXK6vmzOyXthWOrAEUxhr7Z X-Proofpoint-ORIG-GUID: wbiQdMQWpQTXIphEwY1r8lP7mps3iNrS X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-05-08_02,2024-05-06_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 lowpriorityscore=0 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=861 spamscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2405080039 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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, This reverts commit r14-6478-gfda8e2f8292a90 "range: Workaround different type precision between _Float128 and long double [PR112788]" as the fixes for PR112993 make all 128 bits scalar floating point have the same 128 bit precision, this workaround isn't needed any more. Bootstrapped and regress-tested on: - powerpc64-linux-gnu P8/P9 (with ibm128 by default) - powerpc64le-linux-gnu P9/P10 (with ibm128 by default) - powerpc64le-linux-gnu P9 (with ieee128 by default) Is it OK for trunk if {1,2}/4 in this series get landed? BR, Kewen ----- PR target/112993 gcc/ChangeLog: * value-range.h (range_compatible_p): Remove the workaround on different type precision between _Float128 and long double. --- gcc/value-range.h | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/gcc/value-range.h b/gcc/value-range.h index 9531df56988..39de7daf3d9 100644 --- a/gcc/value-range.h +++ b/gcc/value-range.h @@ -1558,13 +1558,7 @@ range_compatible_p (tree type1, tree type2) // types_compatible_p requires conversion in both directions to be useless. // GIMPLE only requires a cast one way in order to be compatible. // Ranges really only need the sign and precision to be the same. - return TYPE_SIGN (type1) == TYPE_SIGN (type2) - && (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) - // FIXME: As PR112788 shows, for now on rs6000 _Float128 has - // type precision 128 while long double has type precision 127 - // but both have the same mode so their precision is actually - // the same, workaround it temporarily. - || (SCALAR_FLOAT_TYPE_P (type1) - && TYPE_MODE (type1) == TYPE_MODE (type2))); + return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) + && TYPE_SIGN (type1) == TYPE_SIGN (type2)); } #endif // GCC_VALUE_RANGE_H -- 2.39.1