https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82612
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
I realize there's no ARRAY_REF but users unfamiliar with GCC internals don't,
nor would they care. I'm less concerned about code that defeats the type
system by using casts (though it would be nice to diagnose those as well if
possible). What I think is important to try to diagnose is mistakes in
otherwise good, clean code. Here's another example:
struct A { char a[4]; };
struct B { struct A a[2]; };
int f (struct B *b)
{
char *p = b[0].a[1].a;
return p[13]; // invalid: MEM[(char *)b_2(D) + 17B];
}
int g (struct B *b)
{
char *p = b[1].a[1].a;
return p[1]; // valid: MEM[(char *)b_2(D) + 17B];
}
There's no way to diagnose this in tree-vrp.c because there's no way to
distinguish the two MEM_REFs at that point (same as in pr82585). This isn't a
shortcoming of the warning code in tree-vrp.c But it is a deficiency in the
-Warray-bounds warning. This coding bug could be detected before the pointer
addition that still has access to the array bounds is folded into a MEM_REF (in
tree-ssa-forwprop.c).
