From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108947 invoked by alias); 10 Nov 2017 00:28:48 -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 108712 invoked by uid 89); 10 Nov 2017 00:28:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=forwprop, Hx-languages-length:1810 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 ESMTP; Fri, 10 Nov 2017 00:28:47 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 40DECC056789; Fri, 10 Nov 2017 00:28:46 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-12.rdu2.redhat.com [10.10.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2755C60E3D; Fri, 10 Nov 2017 00:28:44 +0000 (UTC) Subject: Re: [PATCH] enhance -Warray-bounds to detect out-of-bounds offsets (PR 82455) To: Richard Biener , Martin Sebor Cc: Gcc Patch List References: <79634da6-bf31-b7f0-15f5-0436fc21a51a@gmail.com> <5FF222AD-B155-434B-9C65-721009D1964E@suse.de> <1064925a-ac64-502e-d0dd-85c27e7432f6@gmail.com> From: Jeff Law Message-ID: <6d6e6b84-e4b0-069c-30fa-58e45b2cd4c7@redhat.com> Date: Fri, 10 Nov 2017 01:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00810.txt.bz2 On 11/02/2017 05:48 AM, Richard Biener wrote: > > There were elaborate transforms of ptr + CST to ptr->a.b.c[3] in the > past. We have ripped out _most_ of them because of bad interaction > with dependence analysis and _b_o_s warnings. > > But for example PRE might still end up propagating > > _1 = &ptr->a.b.c; > _2 = (*_1)[i_3]; > > as > > _2 = ptr->a.b.c[i_3]; > > But it's not so much GCC building up GIMPLE expressions that would > cause false positives but "valid" C code and "invalid" C code > represented exactly the same in GCC. Let's say I think this is a key point. > >> Or, if that's not it, what exactly is your concern with this >> enhancement? If it's that it's implemented in forwprop, what >> would be a better place, e.g., earlier in the optimization >> phase? If it's something something else, I'd appreciate it >> if you could explain what. > > For one implementing this in forwprop looks like a move in the > wrong direction. I'd like to have separate warning passes or > at most amend warnings from optimization passes, not add new ones. I tend to agree. That's one of the reasons why I pushed Aldy away from doing this kind of stuff within VRP. What I envision is a pass which does a dominator walk through the blocks. It gathers context sensitive range information as it does the walk. As we encounter array references, we try to check them against the current range information. We could also try to warn about certain pointer computations, though we have to be more careful with those. Though I certainly still worry that the false positive cases which led Aldy, Andrew and myself to look at path sensitive ranges arent' resolved and will limit the utility of doing more array range checking. Jeff