[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
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
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #15 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:dbaabd06aaf4a1b0f2a20671c39148a0bd6ccf0e
commit r12-7452-gdbaabd06aaf4a1b0f2a20671c39148a0bd6ccf0e
Author: Qing Zhao
Date: Wed Mar 2 16:48:37 2022 +
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #13 from 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 rguent...@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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #11 from qinzhao at gcc dot gnu.org --- (In reply to rguent...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #10 from 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 changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #7 from Jakub Jelinek --- > 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #6 from Richard Biener ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Andrew Pinski changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- *** 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #4 from Kees Cook --- The kernel keeps gaining more of these cases, so it'll be important to get this fixed: https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.ca...@perches.com/
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Kees Cook changed: What|Removed |Added CC||kees at outflux dot net --- Comment #3 from Kees Cook --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #2 from Alexander Monakov --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Richard Biener 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 ---
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) >
{
int x;
try
{
_1 = .DEFERRED_INIT (4, 1, 0);
x = _1;
__builtin_clear_padding (&x, 0B, 1);
:
D.1989 = g (&x);
return D.1989;
}
finally
{
x = {CLOBBER};
}
}
