From patchwork Thu Apr 19 18:51:42 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xinliang David Li X-Patchwork-Id: 153851 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 832F5B6FD1 for ; Fri, 20 Apr 2012 04:52:05 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1335466326; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: MIME-Version:Received:Received:Date:Message-ID:Subject:From:To: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=hpiSRb3 oOvO0lzTLu9/LkVnfk+k=; b=IYJRAWu6YXLsbCQtjHi3/sJXGXFHXgH61IV6c3w SVfkmf+JymE9RIHSdylMvAAbFhrEf4NFn1D7m6WaLAnBUPyVlfskgz91UPTbox1l IaYhOb7AsKaIrfO8I6fgFTHK1uKaxIiav9Qv/hS/+v3D+JAd5lG3PnkxzCitIhUA wqcE= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:X-Google-DKIM-Signature:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Content-Type:X-System-Of-Record:X-Gm-Message-State:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=FwbEuG4A8MSNcaSEd7/mHxBpEi9Dv4bndcCbHHyqdQQcG7IMayxqrNnC4AWaqt ajaSNa6uT5XfRQUm7J4eh24yV/K36ibgi2kVLjAnnF2W3tvd8QzRYMxFOt6c2A6v qw2CU35HQl/opd6Z2nyBYyUtc8cto6m1bQqq6yTDeSeU0=; Received: (qmail 1378 invoked by alias); 19 Apr 2012 18:52:00 -0000 Received: (qmail 1368 invoked by uid 22791); 19 Apr 2012 18:51:59 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KHOP_RCVD_TRUST, NORMAL_HTTP_TO_IP, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-lpp01m010-f47.google.com (HELO mail-lpp01m010-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Apr 2012 18:51:43 +0000 Received: by lagw12 with SMTP id w12so6882828lag.20 for ; Thu, 19 Apr 2012 11:51:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=GQhzZLbh0dhLWFyA7NhGGGJ2MC3Ig77Vs6XdKAvAq3I=; b=KqQChRHe4ydd73G8/oxIqoK8eD9qaW+H/pcKZUyAtl+4Zn9IuymrmqhBCl8PlwfIhE 0rc4MlcjIqV86H7kETdHm8U1LSij7JPZ9Vh8gHm8LU2MUVfsVsSgi0CIf6pmqZU3wUds tfIacjlHEcPkQyA/oQ3FnX+qbj0/fHV3QCy72fxtxUj7LI7zIiOBwKPXu4v9U7bSv7+s G3mZQrhDeFqxv7h1CqtuKYIVkfHicUxxfklQG7yCx3gv7JNRwPnYxgSggHcwt4dHkIJY TnU9BQRg+ZlxlcArvxtnShJnLCF5xA0VyxNdqDuDZTFdVdwEvsmX5qhsE5ZT5hvKGWcK VKjA== Received: by 10.152.123.229 with SMTP id md5mr924299lab.34.1334861502245; Thu, 19 Apr 2012 11:51:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.123.229 with SMTP id md5mr924292lab.34.1334861502099; Thu, 19 Apr 2012 11:51:42 -0700 (PDT) Received: by 10.152.4.233 with HTTP; Thu, 19 Apr 2012 11:51:42 -0700 (PDT) Date: Thu, 19 Apr 2012 11:51:42 -0700 Message-ID: Subject: Patch to fix compiler ICE due to bad PRE From: Xinliang David Li To: GCC Patches , Richard Guenther X-System-Of-Record: true X-Gm-Message-State: ALoCoQlgXsTCZpDAcmzV3d1bC1q2PXjm6YUP/zbxBqW4kUZZI0nZKFdYNZ4uWzQj/yqkW95BMatv16wbCaaI0RE75DTTrrRatobLNT5PwIpuMgtNQLnqB3kpnf8g4kuNMzmBfXO1UD1FyfsFysi/5xYK9cKmm76jyA== X-IsSubscribed: yes 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 Compiling the attached test case with -O2 using the trunk compiler, the compiler will ICE. The proposed patch is also attached. The test is under going, but I like to have discussion on the right fix first. thanks, David Analysis: ------------- Here is what is happening: BB6 : (Successor: BB8) MEM_19 = phi(MEM_24, MEM_25) t_9 = operator new (100)@MEM_19 (--> MEM_26) mem_ref(pp_6, -16).x@MEM_26 = t_9 (-->MEM_27) --> (1) BB8: ... MEM_20 = PHI(MEM_27, MEM_24) .... d.2348_15 = mem_ref(pp_6, -16).x@MEM_20 In the loop header BB3 (which dominates BB6 and BB8), BB3: .. pp_31 = phi (pp_6, 0); ... pp_6 = pp_31 + 16 In PRE, ANTIC_IN(BB8) includes mem_ref(pp_31,0),x@MEM_20. After phi translate, ANTIC_OUT(BB6) gets mem_ref(pp_31,0).x@MEM_27. However this expression gets propagated into ANTIC_IN(BB6) even though the memory expression is killed by (1). The root cause is that the alias oracle reports that mem_ref(pp_6, -16) and mem_ref(pp_31, 0) are not aliased as their points-to set do not intersect. As as consequence of the bad aliasing, the operator new calls gets transformed into an gimple assignment -- this gimple assignment becomes the defining statement for MEM_26. In a later UD chain walk, the memory chain stops (and triggers the assert) at this new assignment statement because there is no associated vuse for it. Test case -------------- The case is synthesized -- the real world examples involve lots of inlining etc. int g, *gp[100]; struct V { int* x; int y; }; void foo (V **p, V* end, int i) { *p = 0; V* pp = *p; int s = 100; for (; pp < end; ) { pp++; (pp-1)->x = &g; if (g) { if (g>10) g++; int *t = (int*) operator new (100); (pp-1)->x = t; } else s--; gp[end-pp] = (pp-1)->x + s; } } Patch --------- Index: tree-ssa-structalias.c =================================================================== --- tree-ssa-structalias.c (revision 186600) +++ tree-ssa-structalias.c (working copy) @@ -6137,6 +6137,9 @@ pt_solutions_intersect_1 (struct pt_solu if (pt1->anything || pt2->anything) return true; + if (pt1->null && pt2->null) + return true; + /* If either points to unknown global memory and the other points to any global memory they alias. */ if ((pt1->nonlocal