mbox series

[GCC13,V2,0/2] Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

Message ID EC1BCFDF-E10C-45EA-9CEA-B5C4291CDA49@oracle.com
Headers show
Series Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836 | expand

Message

Qing Zhao July 19, 2022, 2:07 p.m. UTC 
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