I got the 'below array bounds' warning in some code and could reduce it to the following testcase (which results in the 'above array bounds' warning). The warning occurs with optimization level -O2 and above. gcc version 4.3.0 20070622 (experimental) g++-4.3 -c -W -Wall -O2 asiaab.cpp --save-temps asiaab.cpp: In function 'void f()': asiaab.cpp:5: warning: array subscript is above array bounds ================ #include <vector> void g() { std::vector<int> *A = new std::vector<int>[42]; delete[] A; } ================ The warning does not occur with types e.g. 'int' or 'std::pair<int,int>' instead of 'std::vector<int>'.
this is yet another case of the middle end folding memory arithmetics back into an array ref that is out of bounds: operator delete [] ((void *) A + 0xfffffffffffffffc); (from orig dump) later it is: D.2607_30 = &(*D.2517_7)[-4]; operator delete [] (D.2607_30); which will then trigger this warning (because -4 is clearly out of bounds).
unfortunately setting TREE_NO_WARNING on the synthesized delete[] parameters does not help because it is lost during middle end folding
I can reproduce this on powerpc64-linux with a compiler from 20070630 but not with anything after 30070731; can anyone else still reproduce the failure, or has it been fixed?
(In reply to comment #3) > I can reproduce this on powerpc64-linux with a compiler from 20070630 but not > with anything after 30070731; can anyone else still reproduce the failure, or > has it been fixed? I still get it now with a C program: #include <stdio.h> static void f ( char a[3][16]) { printf ("%p", a[2]); } int main (void) { char x[3][16]; f (x); return (0); }
I am not completely sure whether this is the same underlying problem, but I get a bogus warning "array subscript is above array bounds" with the code snippet below when compiled with gcc -c -O3 -Wall: ================= #define N 10 extern long H[N]; long m() { if( H[N-1] > 1 ) { int i; for( i=0; i < N-1; ++i ) if( H[i+1] > 1 ) break; return H[i+1]; } return 0; } ================= Note that the first if-statement guarantees that the break statement is always executed and hence an out-of-bounds access is impossible. This is with gcc 4.3.0 20071116. This gcc version still reproduces the problem posted in comment #4 as well.
*** This bug has been marked as a duplicate of 34197 ***