Ping…. Qing
On May 12, 2021, at 12:16 PM, Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>> wrote: Hi, This is the 3rd version of the patch for the new security feature for GCC. Please take look and let me know your comments and suggestions. thanks. Qing ******Compare with the 2nd version, the following are the major changes: 1. use "lookup_attribute ("uninitialized",) directly instead of adding one new field "uninitialized" into tree_decl_with_vis. 2. update documentation to mention that the new option will not confuse -Wuninitialized, GCC still consider an auto without explicit initializer as uninitialized. 3. change the name of "build_pattern_cst" to more specific name as "build_pattern_cst_for_auto_init". 4. handling of nested VLA; Adding new testing cases (auto-init-15/16.c) for this new handling. 5. Add new verifications of calls to .DEFERRED_INIT in tree-cfg.c; 6. in tree-sra.c, update the handling of "grp_to_be_debug_replaced", bind the lhs variable to a call to .DEFERRED_INIT. 7. In tree-ssa-structalias.c, delete "find_func_aliases_for_deferred_init", return directly for a call to .DEFERRED_INIT in "find_func_aliases_for_call". 8. Add more detailed comments in tree-ssa-uninit.c and tree-ssa.c to explain the special handling on REALPART_EXPR/IMAGPRT_EXPR. 9. in build_pattern_cst_for_auto_init: BOOLEAN_TYPE will be set to zero always; INTEGER_TYPE (?and ENUMERAL_TYPE) use wi::from_buffer in order to correctly handle 128-bit integers. POINTER_TYPE will not assert on SIZE < 32. REAL_TYPE add fallback; 10. changed gcc_assert to gcc_unreachable in several places; 11. add more comments; 12. some style issue changes. ******Please see the version 2 at: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567262.html ******The following 2 items are the ones I didn’t addressed in this version due to further study and might need more discussion: 1. Using __builtin_clear_padding to replace type_has_padding. My study shows: the call to __builtin_clear_padding is expanded during gimplification phase. And there is no __bultin_clear_padding expanding during rtx expanding phase. If so, for -ftrivial-auto-var-init, padding initialization should be done both in gimplification phase and rtx expanding phase. And since the __builtin_clear_padding might not be good for rtx expanding, reusing __builtin_clear_padding might not work. 2. Pattern init to NULLPTR_TYPE and ENUMERAL_TYPE: need more comments from Richard Biener on this. ******The change of the 3rd version compared to the 2nd version are: ******The complete 3rd version of the patch are: <change-against-2nd-version.patch><3rd-version-ftrivial-auto-var-init.patch>
