Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Jul 1, 2022 at 5:32 PM Martin Sebor <msebor@gmail.com> wrote:
>
> On 7/1/22 08:01, Qing Zhao wrote:
> >
> >
> >> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> >>
> >> On Fri, Jul 01, 2022 at 12:55:08PM +0000, Qing Zhao wrote:
> >>> If so, comparing to the current implemenation to have all the checking in middle-end, what’s the
> >>> major benefit of moving part of the checking into FE, and leaving the other part in middle-end?
> >>
> >> The point is recording early what FIELD_DECLs could be vs. can't possibly be
> >> treated like flexible array members and just use that flag in the decisions
> >> in the current routines in addition to what it is doing.
> >
> > Okay.
> >
> > Based on the discussion so far, I will do the following:
> >
> > 1. Add a new flag “DECL_NOT_FLEXARRAY” to FIELD_DECL;
> > 2. In C/C++ FE, set the new flag “DECL_NOT_FLEXARRAY” for a FIELD_DECL based on [0], [1],
> >      [] and the option -fstrict-flex-array, and whether it’s the last field of the DECL_CONTEXT.
> > 3. In Middle end,  Add a new utility routine is_flexible_array_member_p, which bases on
> >      DECL_NOT_FLEXARRAY + array_at_struct_end_p to decide whether the array
> >      reference is a real flexible array member reference.

I would just update all existing users, not introduce another wrapper
that takes DECL_NOT_FLEXARRAY
into account additionally.

> >
> >
> > Middle end currently is quite mess, array_at_struct_end_p, component_ref_size, and all the phases that
> > use these routines need to be updated, + new testing cases for each of the phases.
> >
> >
> > So, I still plan to separate the patch set into 2 parts:
> >
> >    Part A:    the above 1 + 2 + 3,  and use these new utilities in tree-object-size.cc to resolve PR101836 first.
> >                   Then kernel can use __FORTIFY_SOURCE correctly;
> >
> >    Part B:    update all other phases with the new utilities + new testing cases + resolving regressions.
> >
> > Let me know if you have any comment and suggestion.
>
> It might be worth considering whether it should be possible to control
> the "flexible array" property separately for each trailing array member
> via either a #pragma or an attribute in headers that can't change
> the struct layout but that need to be usable in programs compiled with
> stricter -fstrict-flex-array=N settings.

Or an decl attribute.

Richard.

>
> Martin
>
> >
> > Thanks a lot for all your help.
> >
> > Qing
> >
> >>
> >>      Jakub
> >>
> >
>