[PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao]

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:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: change-against-2nd-version.patch
Type: application/octet-stream
Size: 27619 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210512/b72a45b2/attachment-0002.obj>
-------------- next part --------------


******The complete 3rd version of the patch are:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3rd-version-ftrivial-auto-var-init.patch
Type: application/octet-stream
Size: 155730 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210512/b72a45b2/attachment-0003.obj>
-------------- next part --------------