[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 14 Feb 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If we just want to avoid the warning in cases like that (there is nothing wrong
> in the testcases themselves, the warning just warns about an implementation
> detail that a normally uninitialized variable will be really uninitialized even
> despite the -ftrivial-auto-var-init= option), then
> maybe_warn_switch_unreachable
> already has:
>       if (gimple_code (stmt) == GIMPLE_GOTO
>           && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL
>           && DECL_ARTIFICIAL (gimple_goto_dest (stmt)))
>         /* Don't warn for compiler-generated gotos.  These occur
>            in Duff's devices, for example.  */;
> and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also
> avoid warnings on:
> 1) call to .DEFERRED_INIT
> 2) call to __builtin_clear_padding if the second argument is present and
> non-zero
> 3) I guess we would need not to warn on a gimple assign store right after the
> .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs
> anything else?

I think it definitely makes sense to diagnose that we are not
following -ftrivial-auto-init-var=X for a decl.  Maybe we should
do that with -Wtrivial-auto-init-var only though?