> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek <[email protected]> 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.
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.
Thanks a lot for all your help.
Qing
>
> Jakub
>
