From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 731 invoked by alias); 8 Oct 2010 22:19:20 -0000 Received: (qmail 713 invoked by uid 22791); 8 Oct 2010 22:19:19 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Oct 2010 22:19:13 +0000 Received: by bwz7 with SMTP id 7so1101219bwz.20 for ; Fri, 08 Oct 2010 15:19:10 -0700 (PDT) Received: by 10.204.100.12 with SMTP id w12mr2608458bkn.90.1286576349134; Fri, 08 Oct 2010 15:19:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.63.146 with HTTP; Fri, 8 Oct 2010 15:18:49 -0700 (PDT) From: =?ISO-8859-1?Q?Manuel_L=F3pez=2DIb=E1=F1ez?= Date: Fri, 08 Oct 2010 22:19:00 -0000 Message-ID: Subject: Re: GCC and out-of-range constant array indexes? To: Gary Funck Cc: GCC List Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-10/txt/msg00130.txt.bz2 > Would it be possible to compute enough of the control flow graph > to process warnings like this one, without running the > actual optimizations, unless those optimizations are requested? > Would the cost be too high? It is possible to do it quite fast. Clang implements all warnings, including Wuninitialized, in the FE using fast analysis and they claim very low false positives. However, there are various reasons why it has not been attempted in GCC: * GCC is too slow already at -O0, slowing it down further would not be acceptable. So you need a really high-performing implementation. * The FEs are quite complex, and both C and C++ construct gimple in a different way. It would be easier to do the analysis once the FE has finished building generic/gimple. However, * The FEs fold/transform expressions as they go, so you don't have a 1-to-1 relationship between the intermediate representation generated by the FEs and the code. Yet, anything is possible in principle. First, it would need someone to do the work. As far as I know, there is no one planning or willing to work on this. And second, it would need to be accepted by the maintainers. I suggest you clarify the latter before implementing your idea, or you will be seriously disappointed. An alternative would be to move the heavier analysis to an external tool that can be invoked by the compiler and share the same infrastructure. As http://clang-analyzer.llvm.org/ does. However, GCC is many years far away to enable implementing such technology. So perhaps implementing some analysis on the FE would be a more promising approach (despite the caveats mentioned above). But you have to find out if the overhead would be acceptable for the respective maintainers. Cheers, Manuel.