[RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao]

Thanks. I will take a look and fix this issue.

BTW, could you please also re-test -ftrivial-auto-var-init=zero -fauto-var-init-approach=D too? 
And let me know are there new issues for -ftrivial-auto-var-init=zero?

(FYI, I have tested -ftrivial-auto-var-init=zero -fauto-var-init-approach=D and
also -ftrivial-auto-var-init=pattern -fauto-var-init-approach=D on cpu2017, without any issue).


Thanks a lot for your help.

Qing


On Feb 26, 2021, at 3:42 PM, Kees Cook <keescook@chromium.org> wrote:
> 
> On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote:
>> Just noticed that you didn’t add -fauto-var-init-approach=D to the command line.
> 
> Ah-ha! I didn't realize that was needed; thanks. However, now some of the sources crash in a different way. Here's the reproducer:
> 
> $ cat poc.i
> struct a {
>  int b;
>  int array[];
> };
> void c() {
>  struct a d;
> }
> 
> $ gcc -ftrivial-auto-var-init=pattern -fauto-var-init-approach=D -c /dev/null poc.i
> during RTL pass: expand
> poc.i: In function ‘c’:
> poc.i:6:12: internal compiler error: in build_pattern_cst, at tree.c:2652
>    6 |   struct a d;
>      |            ^
> 0x75b572 build_pattern_cst(tree_node*)
>        ../../../gcc/gcc/tree.c:2652
> 0x10db116 build_pattern_cst(tree_node*)
>        ../../../gcc/gcc/tree.c:2612
> 0xb8a230 expand_DEFERRED_INIT
>        ../../../gcc/gcc/internal-fn.c:2980
> 0x970e17 expand_call_stmt
>        ../../../gcc/gcc/cfgexpand.c:2749
> 0x970e17 expand_gimple_stmt_1
>        ../../../gcc/gcc/cfgexpand.c:3844
> 0x970e17 expand_gimple_stmt
>        ../../../gcc/gcc/cfgexpand.c:4008
> 0x9766b3 expand_gimple_basic_block
>        ../../../gcc/gcc/cfgexpand.c:6045
> 0x9780d6 execute
>        ../../../gcc/gcc/cfgexpand.c:6729
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> 
> I assume it's not handling the flex-array happily?
> 
> -- 
> Kees Cook