[PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
Qing Zhao
QING.ZHAO@ORACLE.COM
Wed May 12 17:16:58 GMT 2021
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 --------------
More information about the Gcc-patches
mailing list