[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 24 Jan 2023, qing.zhao at oracle dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
> 
> --- Comment #10 from Qing Zhao <qing.zhao at oracle dot com> ---
> > --- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
> > 
> > GCC handles for example
> > 
> > struct A { char data[1]; };
> > struct B { int n; struct A a; };
> > 
> > as if the a.data[] array is a flex-array.
> 
> Okay. Then the maximum size of __builtin_object_size for it should be -1,
> right?

I think so.

> >  It also handles
> > 
> > struct C { int n; struct A a; int x; };
> > 
> > as if a.data[] can be up to 4 elements large (we allow an array to extend
> > flexibly to padding - but only if it is trailing).
> 
> A little confused here:  
>         when the structure with a trailing flexible-array member is a middle
> field of 
>         an outer structure, GCC extension will treat it as a flexible-array
> too? But the
>         maximum size of this flexible-array will be bounded by the size of the
> padding
>         of that field? 
> Is the above understanding correct?

That's correct - at least when using the get_ref_base_and_extent
API.  I see that when using array_ref_flexible_size_p it doesn't
return true (but it's technically not _flexible_, we just treat it with
a bound size that doesn't match the declared bound).

> >  I see that's not
> > consistently handled though.
> > 
> > I think the [] syntax should follow the C standard as what testcases are
> > accepted/rejected by the frontend and any extensions there should be
> > documented
> 
> Agreed, usually where these extension should be documented?

They are usually documented in doc/extend.texi

> > (those are separate from what the former array_at_struct_end_p
> > allowed semantically
> 
> So, your mean to leave such extension out of ?array_at_struct_end_p? (the
> current ?array_ref_flexible_size_p?)?

The first is handled by the function just fine, it's the second
with the bound size that's not and that isn't a good fit there,
though we do handle padding to the end of a declaration where
we return true.

> Handle them separately instead?

I'm not sure how important it is to hande the middle array
extending to padding, ISTR there was some real world code
"miscompiled" when treating the array domain as written.

Richard.