BTW, if you want some testcase where -fno-aggressive-loop-optimizations still makes a difference even in GCC 4.8.0 release, one testcase is e.g.:
int a[4];
__attribute__((noinline, noclone)) int
foo (int x)
{
int i, r = 0, n = x & 31;
for (i = 0; i < n; i++)
r += a[i];
return r;
}
int
main ()
{
int x = 255;
__asm volatile ("" : "+r" (x));
return foo (x);
}
. With -O3 and not -fno-aggressive-loop-optimizations, GCC from the loop determines the high bound to be 4 and completely unrolls the loop into 4 reads from a (+ additions for 2nd and up iteration) preceeded each by test of the n variable, so the code won't actually read beyond end of a array, while with -O3 -fno-aggressive-loop-optimizations GCC won't compute the upper bound estimate so low (VRP can figure out it is 32, while other passes just estimate INT_MAX), so the loop happily will read beyond end of a, is vectorized (which is unlikely desirable for such small number of iterations), etc. Even without the "& 31" the situation is similar, and certainly for that case I don't see why a warning would be ever useful, the routine just can be valid only when called with a parameter 0 to 3, but there is no reason not to assume all the callers don't do that (the asm is optimization barrier, the compiler isn't supposed to look through it).