From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8224 invoked by alias); 27 Feb 2015 20:00: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 8203 invoked by uid 89); 27 Feb 2015 20:00:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-we0-f171.google.com Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com) (74.125.82.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 27 Feb 2015 20:00:21 +0000 Received: by wesx3 with SMTP id x3so22434806wes.7 for ; Fri, 27 Feb 2015 12:00:18 -0800 (PST) X-Received: by 10.194.174.164 with SMTP id bt4mr25581771wjc.7.1425067218456; Fri, 27 Feb 2015 12:00:18 -0800 (PST) Received: from [10.50.190.128] (089144225128.atnat0034.highway.a1.net. [89.144.225.128]) by mx.google.com with ESMTPSA id ec6sm1004292wib.3.2015.02.27.12.00.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 12:00:17 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <000601d05282$7fabdc60$7f039520$@arm.com> References: <000601d05282$7fabdc60$7f039520$@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] Fix removing of df problem in df_finish_pass From: Bernhard Reutner-Fischer Date: Fri, 27 Feb 2015 20:46:00 -0000 To: Thomas Preud'homme ,gcc-patches@gcc.gnu.org,'Paolo Bonzini' ,'Seongbae Park' ,'Kenneth Zadeck' Message-ID: <0BB350D6-A720-4487-B57E-627AE7D1BF17@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg01723.txt.bz2 On February 27, 2015 12:42:43 PM GMT+01:00, Thomas Preud'homme wrote: >Hi, > >In df_finish_pass, optional problems are removed manually making non >null >entries in df->problems_in_order non contiguous. This may lead to null >pointer >dereference when accessing all problems from df->problems_in_order[0] >to >df->problems_in_order[df->num_problems_defined - 1] and miss some other >problems. Such a scenario was actually encountered when working on a >patch. >This patch use the existing function df_remove_problem to do the >deletion, >which require iterating on problems via the df->problems_by_index[] >array >since each call mess up with df->num_problems_defined and order of >problems in df->problems_in_order[]. > >ChangeLog entry is as follows: > >2015-02-12 Thomas Preud'homme > > * df-core.c (df_finish_pass): Iterate over df->problems_by_index[] and > use df_remove_problem rather than manually removing problems, living leaving Thanks, > holes in df->problems_in_order[]. > >diff --git a/gcc/df-core.c b/gcc/df-core.c >index 82f1364..67040a1 100644 >--- a/gcc/df-core.c >+++ b/gcc/df-core.c >@@ -642,7 +642,6 @@ void > df_finish_pass (bool verify ATTRIBUTE_UNUSED) > { > int i; >- int removed = 0; > > #ifdef ENABLE_DF_CHECKING > int saved_flags; >@@ -658,21 +657,15 @@ df_finish_pass (bool verify ATTRIBUTE_UNUSED) > saved_flags = df->changeable_flags; > #endif > >- for (i = 0; i < df->num_problems_defined; i++) >+ /* We iterate over problems by index as each problem removed will >+ lead to problems_in_order to be reordered. */ >+ for (i = 0; i < DF_LAST_PROBLEM_PLUS1; i++) > { >- struct dataflow *dflow = df->problems_in_order[i]; >- struct df_problem *problem = dflow->problem; >+ struct dataflow *dflow = df->problems_by_index[i]; > >- if (dflow->optional_p) >- { >- gcc_assert (problem->remove_problem_fun); >- (problem->remove_problem_fun) (); >- df->problems_in_order[i] = NULL; >- df->problems_by_index[problem->id] = NULL; >- removed++; >- } >+ if (dflow && dflow->optional_p) >+ df_remove_problem (dflow); > } >- df->num_problems_defined -= removed; > > /* Clear all of the flags. */ > df->changeable_flags = 0; > > >Testsuite was run with a bootstrapped x86_64 native compiler and an >arm-none-eabi GCC cross-compiler targetting Cortex-M3 without any >regression. > >Although the problem is real, it doesn't seem that GCC hits it now >(I stumbled upon it while working on a patch). Therefore I'm not sure >if this should go in stage4 or not. Please advise me on this. > >Ok for trunk/stage1? > >Best regards, > >Thomas