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

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

[amonakov at gcc dot gnu.org]

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

            Bug ID: 102276
           Summary: -ftrivial-auto-var-init fails to initialize a
                    variable, causes a spurious warning
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

int g(int *);
int f1()
{
    switch (0) {
        int x;
        default:
        return g(&x);
    }
}
int f2()
{
    goto L;
    {
        int x;
        L:
        return g(&x);
    }
}

Compiling with -O2 -ftrivial-auto-var-init=pattern causes spurious

warning: statement will never be executed [-Wswitch-unreachable]
    5 |         int x;
      |             ^


In both f1 and f2, resulting assembly does not in fact initialize 'x':

f1:
        subq    $24, %rsp
        leaq    12(%rsp), %rdi
        call    g
        addq    $24, %rsp
        ret
f2:
        subq    $24, %rsp
        leaq    12(%rsp), %rdi
        call    g
        addq    $24, %rsp
        ret

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |qing.zhao at oracle dot com,
                   |                            |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2021-09-13

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Both cases jump past the initialization - for C++ this would be a invalid
testcase I guess while for C we'd warn if the 'x' were initialized.

I'm not sure if it is reasonably possible to "fix" these cases.

Confirmed for the spurious warning, it is emitted by gimplification on

  switch (0) <default: <D.1982>>
  {
    int x;

    try
      {
        _1 = .DEFERRED_INIT (4, 1, 0);
        x = _1;
        __builtin_clear_padding (&x, 0B, 1);
        <D.1982>:
        D.1989 = g (&x);
        return D.1989;
      }
    finally
      {
        x = {CLOBBER};
      }
  }

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

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
That -ftrivial-auto-var-init places an initialization at the point of the
declaration is an implementation detail: there's no initializer in the testcase
itself, so it is valid C and C++ (spelling this out for the avoidance of
doubt).

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

[kees at outflux dot net]

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

Kees Cook <kees at outflux dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kees at outflux dot net

--- Comment #3 from Kees Cook <kees at outflux dot net> ---
Clang shares this problem, though it also lacks a warning, making it a silent
missing initialization:
https://bugs.llvm.org/show_bug.cgi?id=44916

FWIW, the Linux kernel has already purged all these cases, in preparation of
using -ftrivial-auto-var-init:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Distribute+switch+variables+for+initialization

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

[kees at outflux dot net]

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

--- Comment #4 from Kees Cook <kees at outflux dot net> ---
The kernel keeps gaining more of these cases, so it'll be important to get this
fixed:
https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.camel@perches.com/

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nsz at gcc dot gnu.org

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 104504 has been marked as a duplicate of this bug. ***

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

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's difficult, see the recent discussion on introducing explicit live-in
markers for the purpose of stack slot sharing and exactly these case of
testcases.

The "simplest" suggestion was to promote the variable to an outer scope when
such entry into the containing scope is detected.  But since we are doing
auto-init at gimplification time the new point of initializaton would need to
be computed before somehow.

Since you are getting a diagnostic which we could even improve to

warning: variable auto-init for `x' will never be executed

and you do like to get auto-init and you _can_ fix your code that's all
perfectly OK.

Yes, there might be a way to compute auto-init locations (! yes, multiple,
with obvious code-size impact) or a more conservative location (extending
the variable lifetime with the corresponding effect on stack slot sharing).
But clearly fixing the source is prefered.  Mind that when you write

int g(int *);
int f1()
{
    switch (0) {
        int x = 0;
        default:
        return g(&x);
    }
}

you get the very same effect.  So IMHO -ftrivial-auto-var-init behaves
_exactly_ as one would assume it would, without doing any invisible
magic dances.

So yes, let's improve the diagnostic to be specific about each variable
that is not initialized (and maybe the following still unreachable stmt).

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

[jakub at gcc dot gnu.org]

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?

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

[qinzhao at gcc dot gnu.org]

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> 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?
Yes, I think the above 3 should include all the cases.

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

[qinzhao at gcc dot gnu.org]

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
having a patch in my local tree, under testing.

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

[rguenther at suse dot de]

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?

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

[qinzhao at gcc dot gnu.org]

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

--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to rguenther@suse.de from comment #10)

> 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?

currently we don't have -Wtrivial-auto-init-var, do you want to add a new
option -Wtrivial-auto-init-var? what's the purpose of it?

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

[qinzhao at gcc dot gnu.org]

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
I will go with the following solution:

1. avoid emitting switch-unreachable warnings for -ftrivial-auto-var-init;
2. adding a new option -Wtrivial-auto-var-init to emit warnings for the
switch-unreadable cases to suggest the user modify the source code;
3. update documentation of -ftrivial-auto-var-init for the limitation on
switch-unreachable cases and introduce the new option -Wtrivial-auto-var-init

with the above 1, we can resolve the current immediate issue of spurious
warnings of using -ftrivial-auto-var-init to make kernel build succeed;
with the above 2, we provide the user a way to know that
-ftrivial-auto-var-init has limitation on the switch-unreachable cases, and
user should modify the source code to avoid this problem;
with the above 3, we will provide the user a clear documentation of the
-ftrivial-auto-var-init and also provide suggestions how to resolve this issue. 

I will update my current patch with this.

let me know if you have other comments and suggestions.

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

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 15 Feb 2022, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
> 
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to rguenther@suse.de from comment #10)
> 
> > 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?
> 
> currently we don't have -Wtrivial-auto-init-var, do you want to add a new
> option -Wtrivial-auto-init-var? what's the purpose of it?

It's purpose is to diagnose cases where the program might see a not
auto-initialized variable despite using -ftrivial-auto-init-var=...

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

[qinzhao at gcc dot gnu.org]

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

--- Comment #14 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)

> 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?

After more study of the source code for maybe_warn_switch_unreachable, I
realize that in order to emit the switch_unreachable warning,
"warn_switch_unreachable_r" first is called to scan the switch sequence and
saved the FIRST "REAL" gimple stmt.  then it will check this FIRST "REAL" stmt
to see whether it's the LABEL, if it's not, then report the switch unreachable
warning. 

So, we only need to consider the FIRST "REAL" gimple for the above 3 cases. For
all the 3 cases, the FIRST "REAL" gimple is a call to .DEFERRED_INIT. 
So, inside maybe_warn_switch_unreachable, we only need to check whether the
FIRST gimple is a cal .DEFERRED_INIT, that's enough.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Qing Zhao <qinzhao@gcc.gnu.org>:

https://gcc.gnu.org/g:dbaabd06aaf4a1b0f2a20671c39148a0bd6ccf0e

commit r12-7452-gdbaabd06aaf4a1b0f2a20671c39148a0bd6ccf0e
Author: Qing Zhao <qing.zhao@oracle.com>
Date:   Wed Mar 2 16:48:37 2022 +0000

    Don't emit switch-unreachable warnings for -ftrivial-auto-var-init
(PR102276)

    At the same time, adding -Wtrivial-auto-var-init and update documentation.
     -Wtrivial-auto-var-init and update documentation.

    for the following testing case:
    1 int g(int *);
    2 int f1()
    3 {
    4     switch (0) {
    5         int x;
    6         default:
    7         return g(&x);
    8     }
    9 }
    compiling with -O -ftrivial-auto-var-init causes spurious warning:
    warning: statement will never be executed [-Wswitch-unreachable]
    5 |         int x;
      |             ^
    This is due to the compiler-generated initialization at the point of
    the declaration.

    We could avoid the warning  to exclude the following cases:

    when
    flag_auto_var_init > AUTO_INIT_UNINITIALIZED
    And
    1) call to .DEFERRED_INIT
    2) call to __builtin_clear_padding if the 2nd argument is present and
non-zero
    3) a gimple assign store right after the .DEFERRED_INIT call that has the
LHS
       as RHS

    However, we still need to warn users about the incapability of the option
    -ftrivial-auto-var-init by adding a new warning option
-Wtrivial-auto-var-init
    to report cases when it cannot initialize the auto variable. At the same
    time, update documentation for -ftrivial-auto-var-init to connect it with
    the new warning option -Wtrivial-auto-var-init,  and add documentation
    for -Wtrivial-auto-var-init.

    gcc/ChangeLog:

            PR middle-end/102276
            * common.opt (-Wtrivial-auto-var-init): New option.
            * doc/invoke.texi (-Wtrivial-auto-var-init): Document new option.
            (-ftrivial-auto-var-init): Update option;
            * gimplify.cc (emit_warn_switch_unreachable): New function.
            (warn_switch_unreachable_r): Rename to ...
            (warn_switch_unreachable_and_auto_init_r): This.
            (maybe_warn_switch_unreachable): Rename to ...
            (maybe_warn_switch_unreachable_and_auto_init): This.
            (gimplify_switch_expr): Update calls to renamed function.

    gcc/testsuite/ChangeLog:

            PR middle-end/102276
            * gcc.dg/auto-init-pr102276-1.c: New test.
            * gcc.dg/auto-init-pr102276-2.c: New test.
            * gcc.dg/auto-init-pr102276-3.c: New test.
            * gcc.dg/auto-init-pr102276-4.c: New test.

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

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #16 from qinzhao at gcc dot gnu.org ---
Fixed in gcc12