Bug 45180 - bogus warning: array subscript is above array bounds
Summary: bogus warning: array subscript is above array bounds
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.5.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Blocks: Warray-bounds
  Show dependency treegraph
Reported: 2010-08-04 12:58 UTC by Joachim Reichel
Modified: 2017-10-17 16:40 UTC (History)
3 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work: 5.4.0, 6.4.0, 7.1.0, 8.0
Known to fail: 4.8.3, 4.9.3
Last reconfirmed: 2010-08-04 13:09:50


Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Reichel 2010-08-04 12:58:02 UTC
Please see 43949 which was about a very similar test case.

$ cat test.cpp
void f();

int c[3];
int result;

struct Vector {
    static int get(int i) {
        if (i >= 3)
        return c[i];

void g(int index)
    result = Vector::get(index) + Vector::get(index);

$ g++ -Wall -c test.cpp
[no warnings]

$ g++ -Wall -c -O2 test.cpp
test.cpp: In function ‘void g()’:
test.cpp:10:19: error: array subscript is above array bounds

$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/prefix/gcc-4.5.0 --exec-prefix=/prefix/gcc-4.5.0/x86_64-unknown-linux-gnu --enable-version-specific-runtime-libs --enable-stage1-checking --disable-nls --with-system-zlib --enable-multilib --enable-languages=c,c++,objc --with-gmp-include=/prefix/gmp-4.2.2/x86_64-unknown-linux-gnu/include --with-gmp-lib=/prefix/gmp-4.2.2/x86_64-unknown-linux-gnu/lib --with-mpfr-include=/prefix/mpfr-2.4.2/include --with-mpfr-lib=/prefix/mpfr-2.4.2/x86_64-unknown-linux-gnu/lib --with-mpc-include=/prefix/mpc-0.8.1/include --with-mpc-lib=/prefix/mpc-0.8.1/x86_64-unknown-linux-gnu/lib --with-gnu-as --with-as=/prefix/binutils-2.20.1/x86_64-unknown-linux-gnu/bin/as --with-gnu-ld --with-ld=/prefix/binutils-2.20.1/x86_64-unknown-linux-gnu/bin/ld
Thread model: posix
gcc version 4.5.0 (GCC)

The bogus warning disappears if
- Vector::get(index) is assigned to result (no addition)
- get() is a global function

The bogus warning does not appear in gcc 4.2.4 (Debian 4.2.4-6). It appears
also in 4.3.2 (Debian 4.3.2-1.1), 4.4.4 (Debian 4.4.4-7) and 4.5.0 (GCC).

Note that in contrast to PR43949 in this case the array subscript *could* be above array bounds depending on how g() is called, but in the code snippet itself there is no such call.
Comment 1 Richard Biener 2010-08-04 13:09:50 UTC
The reasoning of GCC goes as follows.  There is a partial redundancy
along the two invocations of get(), as c[i] is possibly clobbered by f().
So we transform g() to

  if (i >= 3)
  tem1 = c[i];
  if (i >= 3)
    tem2 = c[i];
  else tem2 = tem1;
  return tem1 + tem2;

now you can see that the load to tem2 is _always_ accessing c with
an out-of-bound index.

There is no code in the warning machinery to restrict the "is above"
warning to code regions that are always executed.
Comment 2 Joachim Reichel 2010-08-04 15:00:42 UTC
Ok, I see. But that seems a bit unfortunate. Isn't there a great deal of such code? Just think of some vector class: c would be a class member, get() non-static and "if...f()" is an assert-like statement (that might return or not).

void f();

int result;

struct Vector {
    int c[3];
    int get(int i) const {
        if (i >= 3)
        return c[i];

void g(const Vector& x, int index)
    result = x.get(index) + x.get(index);


In the original test case if I make get() a global function, then there is no warning. Is the code then transformed differently?

And if I replace the argument in the second call of get() by index+1 I also don't get the warning. I guess that's because the load into tem2 gets moved out of the if-block then?

Just trying to understand how common the problem is ...
Comment 3 Andrew Pinski 2010-08-04 15:44:53 UTC
Since the compiler does not know that f() will never return, it is hard problem to solve.  If you mark f with the attribute noreturn, the warning will disappear.
Comment 4 Martin Sebor 2017-10-17 16:40:25 UTC
The test case doesn't trigger a warning with recent GCC.  Bisection points to  r220157 (gcc 5.0.0) as the fix.  Thus resolving as fixed.