From patchwork Tue Sep 10 19:51:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 1160551 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-508799-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="ao1toPQe"; 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 46SbJf6rSyz9s4Y for ; Wed, 11 Sep 2019 05:51:44 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; q=dns; s= default; b=Y2kLz+YN/lNcQJLV+rfiWYamvESN7viePEueQOwqIeplft/21XJXI vnbEZUXnhDnOuZZbyOC/9HyE0ViU/nb+IwgRGN5IhGWoPo0SCD9/WkbX81h06+9V TcJNugBLQ+55snDrhej5Khzsub8OLO+wQfom+H0Ez64SEl15dOTgTs= 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:from :to:subject:date:message-id:content-type:mime-version; s= default; bh=tTZcIAQt1XIb4HRsJfIONjiE+dk=; b=ao1toPQecsFguiyWKJsp gpLXmn2X39Qk7EkdrIQVQTWEg+WDvsCVbP7/tIjSKyC5sNaCYzFo2ugiz2nqHbML HedYoY4h2oWn76VUSTeo8EhGGt4Ej6MsOZ1O9WZIpn+dTHvqJYV5Fk4K3kjGqGl0 hGPJOEQrvTL/ZnuLdwlC2Mo= Received: (qmail 40115 invoked by alias); 10 Sep 2019 19:51:34 -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 40104 invoked by uid 89); 10 Sep 2019 19:51:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=H*M:COM, H*MI:COM, csec, unspec X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com Received: from mail-oln040092064025.outbound.protection.outlook.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (40.92.64.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Sep 2019 19:51:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FDaLlsU+JfK0WjtNLRD1fdzcgJK+nS1PYbTw2Bj6oh2qlqfewXZzi8iZUVhqvMhyuW8p+9Ia2ocFoMaF3/uV3e6Bl/Gc+KhkRs8BCRF5qThCYEv20KoO8Par048qU/YeONGaIhbuognKZXjbiL+/sL1gr7QGeLOr/BuETEnSVxDRjWSPjDVqB+0pMjYKkCX9QBQnRLFHQCcVh8kfzguJ5u9B0VptPI/zsXLxHRa9eL7e9A9KezMy2eILa9cmzI2G6djLZidDPebgGpLe11V9QYLnx/O9iybNxquyFoJRJwlppVd/Ok5xPilGuP+KC25iotnIT7pQg1VuxSb8gDWQFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6U6kQpAucSfZcuVUfThmb6X4pQ/G/dPXsthnLnRnIR0=; b=e9BhITmqEuMj0IN1RQrOlyZEK98z7eLHa/3W19ZXhY2JFM6v8odKKaJubaLdLyWHwDwu6fb1AuKNeroc/JXs/PQwGdR+bfo7dKBu6ZLQtaQSSJNQeF8UZB3ZPq3QXxzUrs0gNtsWSSAPVILxMuINFRID7Md3ONainjzd5V5h1B40wDySyz65yQLvj0ZT8Akt6chOPGtnZNRR3idG7haanhD1/SLXOjJRF20p9KoDL+tV2gORTSpk+930b16NdH0ZCLZnpGFysQ+Xv2BZozRvyfPRrsSF6LP/F/M2JkpJfZ6D4WXvKwsIbV7syy7AOPMOxoW3tJB7p5hQXTRdbtsufg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR01FT062.eop-EUR01.prod.protection.outlook.com (10.152.0.53) by HE1EUR01HT003.eop-EUR01.prod.protection.outlook.com (10.152.0.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14; Tue, 10 Sep 2019 19:51:28 +0000 Received: from AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM (10.152.0.58) by HE1EUR01FT062.mail.protection.outlook.com (10.152.1.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14 via Frontend Transport; Tue, 10 Sep 2019 19:51:28 +0000 Received: from AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM ([fe80::2c65:b468:fdc0:d924]) by AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM ([fe80::2c65:b468:fdc0:d924%6]) with mapi id 15.20.2241.018; Tue, 10 Sep 2019 19:51:28 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" , Richard Biener , Jeff Law , Jakub Jelinek Subject: [PATCH] Fix PR 91708 Date: Tue, 10 Sep 2019 19:51:28 +0000 Message-ID: x-microsoft-original-message-id: <57eb40c3-8eb3-acc9-b00f-1dc3a86e02aa@hotmail.de> x-ms-exchange-transport-forked: True MIME-Version: 1.0 Hi! This ICE happens when compiling real_nextafter in real.c. CSE sees this: (insn 179 178 180 11 (set (reg:SI 319) (reg/v/f:SI 273 [ rD.73757 ])) "../../gcc-trunk-1/gcc/real.c":120:10 643 {*thumb2_movsi_vfp} (nil)) [...] (insn 181 180 182 11 (set (mem:SI (reg:SI 319) [0 MEM [(voidD.73 *)r_77(D)]+0 S4 A8]) (unspec:SI [ (reg:SI 320) ] UNSPEC_UNALIGNED_STORE)) "../../gcc-trunk-1/gcc/real.c":120:10 129 {unaligned_storesi} (nil)) [...] (insn 186 185 187 11 (set (mem:SI (plus:SI (reg/v/f:SI 273 [ rD.73757 ]) (const_int 20 [0x14])) [0 MEM [(voidD.73 *)r_77(D)]+20 S4 A8]) (unspec:SI [ (reg:SI 320) ] UNSPEC_UNALIGNED_STORE)) "../../gcc-trunk-1/gcc/real.c":120:10 129 {unaligned_storesi} (expr_list:REG_DEAD (reg:SI 320) (expr_list:REG_DEAD (reg/f:SI 319 [ rD.73757 ]) (nil)))) [...] (insn 234 233 235 11 (set (reg:SI 340) (mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32])) "../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp} (nil)) ... and transforms insn 234 in an invalid insn: (insn 234 233 235 11 (set (reg:SI 340 [ MEM [(struct real_valueD.28367 *)r_77(D)] ]) (mem:SI (plus:SI (reg/v/f:SI 273 [ rD.73757 ]) (const_int 20 [0x14])) [0 MEM [(voidD.73 *)r_77(D)]+20 S4 A8])) "../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp} (nil)) which triggers the assertion in the arm back-end, because the MEM is not aligned. To fix that I changed exp_equiv_p to consider MEMs with different MEM_ALIGN or ALIAS_SET as different. This patch fixes the arm bootstrap for --with-cpu=cortex-a57 --with-mode=thumb --with-fpu=fp-armv8 --with-float=hard which I confirmed using a cross compiler. And it fixes the test case that is attached to the PR, but it is way too large for the test suite. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. 2019-09-10 Bernd Edlinger PR middle-end/91708 * cse.c (exp_equiv_p): Consider MEMs with different alias set or alignment as different. --- gcc/cse.c.orig 2019-07-24 21:21:53.590065924 +0200 +++ gcc/cse.c 2019-09-10 16:15:37.899933738 +0200 @@ -2637,8 +2637,13 @@ exp_equiv_p (const_rtx x, const_rtx y, i if (GET_MODE (x) != GET_MODE (y)) return 0; - /* MEMs referring to different address space are not equivalent. */ - if (code == MEM && MEM_ADDR_SPACE (x) != MEM_ADDR_SPACE (y)) + /* MEMs referring to different address spaces are not equivalent. + MEMs with different alias sets are not equivalent either. + Also the MEM_ALIGN needs to be identical in order not to break + constraints of insn's that need certain alignment (see PR91708). */ + if (code == MEM && (MEM_ADDR_SPACE (x) != MEM_ADDR_SPACE (y) + || MEM_ALIAS_SET (x) != MEM_ALIAS_SET (y) + || MEM_ALIGN (x) != MEM_ALIGN (y))) return 0; switch (code)