I have seen it in the early IL but this late I couldn't come up with a test case where such a loop would be necessary. The COMPONENT_REF always refers to the member array. If you can show me an example to test with I'll add the handling if possible. There are cases where it isn't, such as instruct A { char a[4] __attribute__ ((nonstring)); } *pa; strlen (pa->a + 1); where pa->a is represented as a MEM_REF (char[4], pa, 1) with the member information having been lost in translation. (This is the same problem that I had solved for the -Warray-bounds warning for out-of bounds offsets by implementing it in tree-ssa-forwprop.c: because that's where the member is folded into a reference to the base object.)Set up a nested structure then reference it like a.b.c.d.
I did that. From my reply to Jakub: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01671.html with struct A { char a[4], b[4] __attribute__ ((nonstring)); }; struct B { struct A a; }; struct C { struct B b; }; void f (struct C *p) { __builtin_strcpy (p->b.a.a, p->b.a.b); } in get_attr_nonstring_decl() where EXPR is p->a.b.b it is a COMPONENT_REF (COMPONENT_REF (..,), FIELD_DECL (b)). I.e., the outermost FIELD_DECL is the one of interest. The code extracts TREE_OPERAND (decl, 1) from this outermost COMPONENT_REF, which is FIELD_DECL (b). What test case gives a structure where it's necessary to loop over the components to get at the field? I can't think of one. Martin
