From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100507 invoked by alias); 14 Aug 2015 20:46:57 -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 99965 invoked by uid 89); 14 Aug 2015 20:46:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 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:46:55 +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 E120683F99; Fri, 14 Aug 2015 20:46:53 +0000 (UTC) Received: from redhat.com (ovpn-204-94.brq.redhat.com [10.40.204.94]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7EKkn4D025284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2015 16:46:52 -0400 Date: Fri, 14 Aug 2015 21:48:00 -0000 From: Marek Polacek To: Jeff Law Cc: Richard Biener , GCC Patches Subject: Re: [PATCH] Fix middle-end/67133, part 1 Message-ID: <20150814204649.GC2093@redhat.com> 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> <55CE5054.5080400@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55CE5054.5080400@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-08/txt/msg00834.txt.bz2 On Fri, Aug 14, 2015 at 02:32:20PM -0600, Jeff Law wrote: > 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. Yeh, I thought as much. > 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. I suppose both ought to work. Or at least theoretically we could run e.g. cleanup_cfg to prune the IR after we've inserted trap and removed trailing stmts so that it gets rid of unreachable bbs. Would that make sense? Anyway, if you think of how would you like to solve this I can take a crack at it next week. Marek