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?
