From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13753 invoked by alias); 30 Dec 2011 08:29:11 -0000 Received: (qmail 13744 invoked by uid 22791); 30 Dec 2011 08:29:10 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from asav3.lyse.net (HELO asav3.lyse.net) (81.167.37.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Dec 2011 08:28:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by asav3.lyse.net (Postfix) with ESMTP id 9B02D84076; Fri, 30 Dec 2011 09:28:54 +0100 (CET) Received: from localhost.localdomain (unknown [79.161.10.130]) by asav3.lyse.net (Postfix) with ESMTP id 17C768406D; Fri, 30 Dec 2011 09:28:54 +0100 (CET) Received: from [192.168.0.60] (helo=[192.168.0.60]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1RgXpd-00062S-W1; Fri, 30 Dec 2011 09:28:54 +0100 Message-ID: <4EFD75AA.5030800@westcontrol.com> Date: Fri, 30 Dec 2011 12:08:00 -0000 From: David Brown User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ian Lance Taylor CC: gcc-help@gcc.gnu.org Subject: Re: False positive from -Warray-bounds? References: <20111229235727.GU5641@xvii.vinc17.org> <20111230003821.GW5641@xvii.vinc17.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg00275.txt.bz2 On 30/12/2011 05:59, Ian Lance Taylor wrote: > Vincent Lefevre writes: > >> On 2011-12-29 16:20:48 -0800, Ian Lance Taylor wrote: >>> To me this only proves that the compiler is not smart enough to see that >>> (s>> 1 == 0) implies that ((s& 0xffff) == 0xffff) can not be true. >>> >>> Are you suggesting that the compiler should never warn if there is a >>> conditional guarding the array access? Would that in practice be better >>> or worse than the current behaviour? >> >> I think there should be two different options: >> * one that would trigger the warning if the compiler can prove >> that there will always be an out-of-bound access when the >> function is executed (unless the compiler can prove that the >> function will never be executed); >> * one that would trigger the warning if there may be an out-of-bound >> access. > > I wonder how often the first one would actually trigger. And I wonder > how much correct code the second one triggers on today. I personally > think it would be reasonable to rewrite the original example to avoid > the warning, since the code certainly looks like it can generate an out > of bounds access. > The first one quickly reduces to the halting problem, amongst other issues. Consider : static int a[10]; extern int foo(int x); void bar(void) { if (foo(1)) a[100]++; } You can't make a "no false negatives" warning here - it depends entirely on foo, what it returns, and /if/ it returns. If code looks dodgy, it should be warned as dodgy - that's what warnings are for. If you want to write code that looks dodgy but isn't, as one sometimes does, then disable the warning - either omit it from the command line, or use "#pragma GCC diagnostic" around the code in question. Warnings are there to help people write clearer code and avoid common or accidental mistakes - a warning that triggers on /possible/ out-of-bound array access fits that purpose fine (IMHO, of course). If the compiler could tell without any doubt that the array is being accessed illegally, then maybe an error would be better (since the code has undefined behaviour at run-time, is the compiler allowed to reject it?). > >> BTW, can the user inform the compiler that some condition holds? >> i.e. some kind of assert() but specifically for the compiler. > > As far as I know there is no way to do this directly. The closest you > can come is something like > > if (!condition_which_must_be_true ()) > __builtin_unreachable (); > > This will help the compiler in some cases but it won't track a complex > condition in any useful way. > > Ian > Some sort of general way to provide information to the compiler via assertions would be /really/ nice. The most useful case I could think of would be to specify ranges of a variable or expression - if the compiler could track those ranges and use them for warnings and optimisation. Imagine the possibilities of a generalised "nonnull" function parameter attribute with range limits, and the benefits that would have for compile-time error checking!