From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15659 invoked by alias); 27 Oct 2009 16:53:55 -0000 Received: (qmail 15588 invoked by uid 48); 27 Oct 2009 16:53:43 -0000 Date: Tue, 27 Oct 2009 16:53:00 -0000 Message-ID: <20091027165343.15587.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/41847] warning: array subscript is above array bounds In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg02320.txt.bz2 ------- Comment #3 from jakub at gcc dot gnu dot org 2009-10-27 16:53 ------- The issue is that for some strange reason VRP sees the loop iterator (which is [0, 4) ) as VARYING. Then the fDum = get(b, b) is called when b is not 3, and get uses the return maLine[nRow].get(nColumn); for nRow < 3. So, VRP figures that in return mpLine->get(nColumn); nColumn (== b) is necessarily [4, 65535] and reports out of bounds access on something that will really never be executed. If VRP figured that b is [0, 4), it would have been able to tell that the bb's are unreachable and not report diagnostics in that case. I wonder what related runtime failure you are talking about though, this to me looks like a false positive on something that is never executed (although not optimized out at least until *.optimized dump). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847