Hi, Based on the previous discussion on the Version 1 of the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597350.html https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598010.html We decided: *****User interface: . command line option in C/C++: -fstrict-flex-array[=N] (N=0, 1, 2, 3) . decl attribute for FIELD_DECL: strict_flex_array (N) (N=0, 1, 2, 3) *****Implementation: 1. Add a new IR 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, the attribute strict_flex_array and whether it’s the last field of the DECL_CONTEXT. 3. In Middle end, update any place that treats trailing array as flexible array member with the new flag DECL_NOT_FLEXARRAY + array_at_struct_end_p to control the behavior with Multiple level consistently. Then the above implementation will be divided into the following 3 parts: Part A: 1 + 2 Part B: In Middle end, use the new flag in tree-object-size.cc to resolve PR101836, then kernel can use __FORTIFY_SOURCE correctly after this; Part C: in Middle end, use the new flag in all other places that use “array_at_struct_end_p” or “component_ref_size” to make GCC consistently behave for trailing array. This set of patches (2 patches in total, the #1 is for Part A, and #2 is for Part B) are for the above Part A and Part B. NOTE: After this set of patches, the one major issue remained in GCC is, different phases that call either “array_at_struct_end_p” or “component_ref_size” behave inconsistently on the default behavior of what’s a flexible array member, some phases treat all trailing array as flexible array member by default, and some phases treat trailing [], [0], [1] as flexible array member by default. Such inconsistency need to be resolved in Part C. I have bootstrapped and regression tested on both aarch64 and x86, no issues. Let me know if you have any comments on the patches. Thanks. Qing