From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-117428-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1693 invoked by alias); 18 Jul 2005 16:44:13 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 1672 invoked by uid 22791); 18 Jul 2005 16:44:08 -0000
Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 18 Jul 2005 16:44:08 +0000
Received: from localhost (localhost [127.0.0.1])
	by filtered-nile.gnat.com (Postfix) with ESMTP id F143E9625;
	Mon, 18 Jul 2005 12:44:06 -0400 (EDT)
Received: from nile.gnat.com ([127.0.0.1])
 by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 18302-02-7; Mon, 18 Jul 2005 12:44:06 -0400 (EDT)
Received: from [127.0.0.1] (taconic.gnat.com [205.232.38.103])
	by nile.gnat.com (Postfix) with ESMTP id C453F961F;
	Mon, 18 Jul 2005 12:44:06 -0400 (EDT)
Message-ID: <42DBDC54.2090304@adacore.com>
Date: Mon, 18 Jul 2005 16:44:00 -0000
From: Robert Dewar <dewar@adacore.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Sebastian Pop <sebastian.pop@cri.ensmp.fr>
CC: Kai Henningsen <kaih@khms.westfalen.de>,  gcc@gcc.gnu.org
Subject: Re: basic VRP min/max range overflow question
References: <BED9A4B3.A88B%schlie@comcast.net> <Pine.LNX.4.61.0506181606220.24758@digraph.polyomino.org.uk> <Pine.LNX.4.61.0506181606220.24758@digraph.polyomino.org.uk> <42B48D43.2070100@adacore.com> <9Z96FTq1w-B@khms.westfalen.de> <42B54D96.2050006@adacore.com> <20050620132549.GA6005@napoca.cri.ensmp.fr> <42B83061.6090803@adacore.com> <20050718163826.GA22424@napoca.cri.ensmp.fr>
In-Reply-To: <20050718163826.GA22424@napoca.cri.ensmp.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2005-07/txt/msg00792.txt.bz2

Sebastian Pop wrote:

> I don't really see what a false positive could be in this case.  In
> the patch that I have proposed, the warning is triggered every time
> the flag -Wloop-bound-estimated is used and the loop optimizer
> triggers the estimation of loop bounds for a parametric loop, as in
> the following:
> 
> void foo (int N)
> {
>   int i;
>   int A[123];
> 
>   for (i = 0; i < N; i++)
>     A[i] = ...
> }
> 
> The warning would say something like "<file>:<line> undefined behavior
> if loop runs more than 122 iterations: access over allocated data
> bounds".

and that is called a false positive if in fact the loop does
not overrun. this sounds very dubious to me