On April 17, 2015 8:01:42 PM GMT+02:00, Steve Ellcey <sell...@imgtec.com> wrote:
>On Thu, 2015-04-16 at 13:55 +0200, Richard Biener wrote:
>> The following applies the patch produced earlier this year, applying
>> TLC to array bound warnings and catching a few more cases.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>>
>> Richard.
>>
>> 2015-04-16 Richard Biener <rguent...@suse.de>
>>
>> PR tree-optimization/64277
>> * tree-vrp.c (check_array_ref): Fix anti-range handling,
>> simplify upper bound handling.
>> (search_for_addr_array): Simplify.
>> (check_array_bounds): Handle ADDR_EXPRs here.
>> (check_all_array_refs): Simplify.
>
>This caused an interesting build failure of glibc when using the latest
>GCC. Here is a cut down case from elf/dl-open.c:
>
> extern void foo(void);
> struct s { int n; } v[1];
> int bar (int i)
> {
> if ((i != 0 && i != -1 && i != -2) && (v[i].n == 0))
> foo ();
> return 0;
> }
> int baz (int i)
> {
> if ((i != 0 && i != -2) && (v[i].n == 0))
> foo ();
> return 0;
> }
>
>When compiled with -O2 -Wall -Werror, I now get an error about v[i]
>being out-of-bounds in bar. But I do not get this error in baz (where
>we don't check for -1. In reality, in glibc, we know that i can only
>be
>0, -1, or -2. GCC of course doesn't know that. Does this
>error/warning
>seem right?
Yes. Once you reach the array reference it will be out of bounds.
The difference in behavior between bar and baz seems odd.
>
Yeah, I suppose VRP gets conservative in a way that's not helpful for
consistency of this warning. ~[0,0] and ~[-2,-2] likely meet as VARYING and
the warning code doesn't look at equivalences.
Richard.
>Steve Ellcey
>sell...@imgtec.com
