Hi, Consider the following example. extern unsigned int foo (int*) __attribute__((pure)); unsigned int tr (int array[], int n) { unsigned int i; unsigned int sum = 0; for (i = 0; i < n; i++) sum += foo (&array[i]); return sum; } For 32-bit pointers, the analysis in infer_loop_bounds_from_pointer_arith currently concludes that the range of valid &array[i] is &array[0x0] to &array[0x3fffffff], meaning 0x40000000 distinct values. This implies that i < n is executed at most 0x40000001 times, and i < n cannot be eliminated by an 32-bit iterator with step 4, since that one has only 0x40000000 distinct values. The patch reasons that NULL cannot be used or produced by pointer arithmetic, and that we can exclude the possibility of the NULL pointer in the range. So the range of valid &array[i] is &array[0] to &array[0x3ffffffe], meaning 0x3fffffff distinct values. This implies that i < n is executed at most 0x40000000 times and i < n can be eliminated. The patch implements this new limitation by changing the (low, high, step) triplet in infer_loop_bounds_from_pointer_arith from (0x0, 0xffffffff, 0x4) to (0x4, 0xffffffff, 0x4). I'm not too happy about the test for C-like language: ptrdiff_type_node != NULL_TREE, but I'm not sure how else to test for this. Bootstrapped and reg-tested on x86_64. I will sent the adapted test cases in a separate email. OK for trunk? Thanks, - Tom 2011-06-15 Tom de Vries PR target/45098 * tree-ssa-loop-niter.c (infer_loop_bounds_from_pointer_arith): Disallow NULL pointer for pointer arithmetic.