On 7/1/22 08:01, Qing Zhao wrote:
On Jul 1, 2022, at 8:59 AM, Jakub Jelinek <ja...@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.
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.
Martin
Thanks a lot for all your help.
Qing
Jakub
