On 11/19/2017 03:26 PM, Martin Sebor wrote:
>>> 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 in
>>>
>>> struct 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.
Bah. It's so damn easy to forget that the outermost COMPONENT_REF
refers to the last component in the expression.
Can you incorporate the lazy initialization from Jakub and commit?
Jeff
