From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86651 invoked by alias); 15 Nov 2017 00:52:07 -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 86633 invoked by uid 89); 15 Nov 2017 00:52:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=bloody, walker 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; Wed, 15 Nov 2017 00:52:05 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DBB1C3680E; Wed, 15 Nov 2017 00:52:03 +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 C57C72C8CF; Wed, 15 Nov 2017 00:52:02 +0000 (UTC) Subject: Re: [PATCH] enhance -Warray-bounds to detect out-of-bounds offsets (PR 82455) To: Richard Biener Cc: Martin Sebor , 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> <6d6e6b84-e4b0-069c-30fa-58e45b2cd4c7@redhat.com> From: Jeff Law Message-ID: <4c072ed3-6b14-01f0-b22a-4490f9350cfc@redhat.com> Date: Wed, 15 Nov 2017 01:52: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/msg01139.txt.bz2 On 11/14/2017 01:42 AM, Richard Biener wrote: > > I suspect once you're dealing with C++ code you run into the issue > that even early inlining exposes code with forwprop run on it > before running forwprop again on the inlined-into body. > > So the IPA issues start very early. Of course if you are doing > path-sensitive processing then processing call/return "edges" as if > they were CFG edges shouldn't be too hard. > > Then the only issue remaining is that there are very many > paths in a program compared to # edges or # blocks which means > you'll quickly run into compile-time issues. Yup. There's a reason why static analysis is usually not on by default. It's bloody expensive. > > Static analyzers are hard ;) But I appreciate somebody finally > trying that route. Ideally we'd do the static analysis in parallel > to the compilation given we'd need an "early" LTO phase before > early inlining. Thus do a LTO out then in parallel do WPA > static analysis with diagnostics. > No doubt. I wouldn't even say we're going that route, at least not in any real sense. The walkers would probably be structured differently than what we're doing and have to hook in much earlier. You have to build both the callgraph walker as well as the CFG walker and the ability to pass data back and forth between them. You'd also have to finish all the deferred folding stuff so that what you analyze is closer to the actual source. We're just building on the existing infrastructure we have to give better function scoped warnings. jeff