From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122867 invoked by alias); 14 Aug 2015 19:58:44 -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 122853 invoked by uid 89); 14 Aug 2015 19:58:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,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 19:58:42 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 870A94C0BA; Fri, 14 Aug 2015 19:58:41 +0000 (UTC) Received: from redhat.com (ovpn-204-94.brq.redhat.com [10.40.204.94]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7EJwalg010172 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2015 15:58:39 -0400 Date: Fri, 14 Aug 2015 20:12:00 -0000 From: Marek Polacek To: Jeff Law Cc: Richard Biener , GCC Patches Subject: Re: [PATCH] Fix middle-end/67133, part 1 Message-ID: <20150814195836.GB2093@redhat.com> References: <20150814112006.GR3335@redhat.com> <20150814132945.GS3335@redhat.com> <55CE002E.6000108@redhat.com> <20150814153224.GU3335@redhat.com> <55CE0A5A.4070802@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55CE0A5A.4070802@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-08/txt/msg00828.txt.bz2 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... Marek