From patchwork Thu Nov 9 21:52:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Meissner X-Patchwork-Id: 836515 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-466453-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="ZTp/c2Po"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3yXxj942rTz9sPt for ; Fri, 10 Nov 2017 08:52:28 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:mime-version:content-type:message-id; q=dns; s= default; b=lybefTzlTxqi0PYe0Nxe66s/aClT+HUQxe78LOq9uDZttxV+NMQ71 LwwSxVLyiEqGS3v6G3CYC5KMGveEBBu2QV8cLl8qwpBANNWmCOlv/fq5pD+uDet7 b2ejILCAqaQ1I+Spb0oaD0pNlHMLWo3iIsP16I41Qm/5yIclEnszCE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:mime-version:content-type:message-id; s= default; bh=v/sO/P0fw/W3X+X8ztnw38DSyxU=; b=ZTp/c2Po3iba4MEYpaKK w0xUMGaU04O9sNXDrQeK1AY1tK1EFGkEgHxh0HRU4MQcVQohyKE0fl/OyBNDDko/ uhvBg1kOwc4mAwfEUasatLaf+ehxRMvalWslDpkOwIiFYOF09F163yNxwD84OhUX MNXyyWOsLAtHeAKULewHwiU= Received: (qmail 9183 invoked by alias); 9 Nov 2017 21:52:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 9173 invoked by uid 89); 9 Nov 2017 21:52:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Nov 2017 21:52:17 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA9Lnvgd154362 for ; Thu, 9 Nov 2017 16:52:12 -0500 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0b-001b2d01.pphosted.com with ESMTP id 2e4u70bm57-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 09 Nov 2017 16:52:12 -0500 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 9 Nov 2017 16:52:11 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (9.57.198.24) by e13.ny.us.ibm.com (146.89.104.200) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 9 Nov 2017 16:52:08 -0500 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vA9Lq70353870746; Thu, 9 Nov 2017 21:52:07 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 62AF2B2050; Thu, 9 Nov 2017 16:49:19 -0500 (EST) Received: from ibm-tiger.the-meissners.org (unknown [9.32.77.111]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id 3EE54B2052; Thu, 9 Nov 2017 16:49:19 -0500 (EST) Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id 0672945D11; Thu, 9 Nov 2017 16:52:06 -0500 (EST) Date: Thu, 9 Nov 2017 16:52:06 -0500 From: Michael Meissner To: GCC Patches , Segher Boessenkool , David Edelsohn , Bill Schmidt Subject: [PATCH], PR middle_end/82333, Make long double/_Float128 constants not hash to the same value on the PowerPC Mail-Followup-To: Michael Meissner , GCC Patches , Segher Boessenkool , David Edelsohn , Bill Schmidt MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17110921-0008-0000-0000-0000029E1327 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008040; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000239; SDB=6.00943560; UDB=6.00476073; IPR=6.00723843; BA=6.00005682; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017940; XFM=3.00000015; UTC=2017-11-09 21:52:09 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17110921-0009-0000-0000-00003743352F Message-Id: <20171109215206.GA8602@ibm-tiger.the-meissners.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711090293 X-IsSubscribed: yes This patch fixes PR middle_end/82333. The bug is due to compare_constant thinking two floating point constants are the same if the floating point size and the internal value are the same. On the PowerPC, long double and _Float128 both are 128-bits, but they have different internal representations. The bug shows up when you try to inline two functions, one that returns 0 converted to long double _Complex and the other that returns 0 converted to _Float128 _Complex. The function compare_constant in varasm.c thinks that these two constants are the same, and assigns them to the same hash. When inliner tries to replace the inline function (that returns 0) with the constant, it does moves of the real part and the imaginary part. In the second function, the real/imaginary parts have type KFmode, while the first function (that has the saved constant) the real/imaginary parts have type TFmode. The fix is to consider the type along with the precision when doing hash of the constants. I have done bootstraps on x86-64 and little endian power8 systems. Both systems bootstrapped fine and there were no regressions in the test suite. I verified that the new test case in the powerpc test directory passes. Can I check this into the trunk? Can I also check this info the active branches (gcc 6/7) providing it causes no regressions? [gcc] 2017-11-09 Michael Meissner PR middle_end/82333 * varasm.c (compare_constant): Take the mode of the constants into account when comparing floating point constants. [gcc/testsuite] 2017-11-09 Michael Meissner PR middle_end/82333 * gcc.target/powerpc/pr82333.c: New test. Index: gcc/varasm.c =================================================================== --- gcc/varasm.c (revision 254556) +++ gcc/varasm.c (working copy) @@ -3118,10 +3118,16 @@ compare_constant (const tree t1, const t return tree_int_cst_equal (t1, t2); case REAL_CST: - /* Real constants are the same only if the same width of type. */ + /* Real constants are the same only if the same width of type. In + addition to the same width, we need to check whether the modes are the + same. There might be two floating point modes that are the same size + but have different representations, such as the PowerPC that has 2 + different 128-bit floating point types (IBM extended double and IEEE + 128-bit floating point). */ if (TYPE_PRECISION (TREE_TYPE (t1)) != TYPE_PRECISION (TREE_TYPE (t2))) return 0; - + if (TYPE_MODE (TREE_TYPE (t1)) != TYPE_MODE (TREE_TYPE (t2))) + return 0; return real_identical (&TREE_REAL_CST (t1), &TREE_REAL_CST (t2)); case FIXED_CST: Index: gcc/testsuite/gcc.target/powerpc/pr82333.c =================================================================== --- gcc/testsuite/gcc.target/powerpc/pr82333.c (revision 0) +++ gcc/testsuite/gcc.target/powerpc/pr82333.c (revision 0) @@ -0,0 +1,34 @@ +/* { dg-do compile { target { powerpc*-*-linux* } } } */ +/* { dg-require-effective-target ppc_float128_sw } */ +/* { dg-require-effective-target vsx_hw } */ +/* { dg-options "-mvsx -O2 -mabi=ibmlongdouble -Wno-psabi" } */ + +/* PR 82333 was an internal compiler abort where the compiler thought that a + long double _Complex constant was the same as __float128 _Complex. */ + +_Complex long double vld; +_Complex _Float128 vf128; + +_Complex long double +fld (_Complex long double arg0) +{ + return 0; +} + +_Complex _Float128 +ff128 (_Complex _Float128 arg0) +{ + return 0; +} + +void +tld (void) +{ + vld = fld (vld); +} + +void +tf128 (void) +{ + vf128 = ff128 (vf128); +}