From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3240 invoked by alias); 2 Dec 2015 08:33: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 3225 invoked by uid 89); 2 Dec 2015 08:33:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 02 Dec 2015 08:33:55 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 74CF6AAB4; Wed, 2 Dec 2015 08:33:51 +0000 (UTC) Date: Wed, 02 Dec 2015 08:33:00 -0000 From: Richard Biener To: Jeff Law cc: Alan Lawrence , gcc-patches@gcc.gnu.org, jakub@redhat.com Subject: Re: [PATCH] Empty redirect_edge_var_map after each pass and function In-Reply-To: <565E2174.3030607@redhat.com> Message-ID: References: <1448994839-10665-1-git-send-email-alan.lawrence@arm.com> <565E2174.3030607@redhat.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2015-12/txt/msg00203.txt.bz2 On Tue, 1 Dec 2015, Jeff Law wrote: > On 12/01/2015 11:33 AM, Alan Lawrence wrote: > > > > I was not able to reduce the testcase below about 30k characters, with e.g. > > #define T_VOID 0 > > .... T_VOID .... > > producing the ICE, but manually changing to > > .... 0 .... > > preventing the ICE; as did running the preprocessor as a separate step, or a > > wide variety of options (e.g. -fdump-tree-alias). > Which is almost always an indication that there's a memory corruption, or > uninitialized memory read or something similar. > > > > > > In the end I traced this to loop_unswitch reading stale values from the edge > > redirect map, which is keyed on 'edge' (a pointer to struct edge_def); the > > map > > entries had been left there by pass_dominator (on a different function), and > > by > > "chance" the edge *pointers* were the same as to some current edge_defs > > (even > > though they pointed to structures created by different allocations, the > > first > > of which had since been freed). Hence the fragility of the testcase and > > environment. > Right. So the question I have is how/why did DOM leave anything in the map. > And if DOM is fixed to not leave stuff lying around, can we then assert that > nothing is ever left in those maps between passes? There's certainly no good > reason I'm aware of why DOM would leave things in this state. It happens not only with DOM but with all passes doing edge redirection. This is because the map is populated by GIMPLE cfg hooks just in case it might be used. But there is no such thing as a "start CFG manip" and "end CFG manip" to cleanup such dead state. IMHO the redirect-edge-var-map stuff is just the very most possible unclean implementation possible. :( (see how remove_edge "clears" stale info from the map to avoid even more "interesting" stale data) Ideally we could assert the map is empty whenever we leave a pass, but as said it triggers all over the place. Even cfg-cleanup causes such stale data. I agree that the patch is only a half-way "solution", but a full solution would require sth more explicit, like we do with initialize_original_copy_tables/free_original_copy_tables. Thus require passes to explicitely request the edge data to be preserved with a initialize_edge_var_map/free_edge_var_map call pair. Not appropriate at this stage IMHO (well, unless it turns out to be a very localized patch). Richard.