From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78799 invoked by alias); 14 Aug 2015 20:32:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 78788 invoked by uid 89); 14 Aug 2015 20:32:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 14 Aug 2015 20:32:22 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 1C5688CF4D; Fri, 14 Aug 2015 20:32:21 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7EKWKUw018073; Fri, 14 Aug 2015 16:32:20 -0400 Subject: Re: [PATCH] Fix middle-end/67133, part 1 To: Marek Polacek References: <20150814112006.GR3335@redhat.com> <20150814132945.GS3335@redhat.com> <55CE002E.6000108@redhat.com> <20150814153224.GU3335@redhat.com> <55CE0A5A.4070802@redhat.com> <20150814195836.GB2093@redhat.com> Cc: Richard Biener , GCC Patches From: Jeff Law Message-ID: <55CE5054.5080400@redhat.com> Date: Fri, 14 Aug 2015 20:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150814195836.GB2093@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00832.txt.bz2 On 08/14/2015 01:58 PM, Marek Polacek wrote: > On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote: >>> Ok, I'll investigate and come back to y'all when/if I find something. >> Thanks. I still regret using the TREE_TYPE as a way to chain elements in >> the free list:( I didn't want to add another pointer field... > > It's actually plain to see what's happening. Before isolate-paths we've got > > : > ... > SR.5_10 = MEM[(const struct A &)0B]; > ... > c_13 = C::size (&p1); > ... > if (_14 != 0) > goto ; > else > goto ; > > : > fn1 (&D.2434.OutBufCur, &b, c_13); > > Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the > stmts in bb 2 and we find a null dereference, so insert_trap_and_remove_trailing_statements > comes in play and turns bb 2 into: > > : > ... > SR.5_10 = MEM[(const struct A &)0B]; > __builtin_trap (); > > i.e. it removs the defining statement for c_13. Then find_explicit_erroneous_behaviour > walks over bb 3, hits the fn1 (&D.2434.OutBufCur, &b, c_13); statement, and > ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE. > > The question now is what to do with that. Skip SSA_NAME_IN_FREE_LIST? That > sounds weird. Note that we're going to remove bb 3 and bb 4 anyway... Jeez, looking at the code N years later, I feel like a complete idiot. Of course that's not going to work. We certainly don't want to peek at SSA_NAME_IN_FREE_LIST. I wonder if we should be walking in backwards dominator order to avoid these effects. Or maybe just ignoring any BB with no preds. I'll ponder those over the weekend. Jeff