[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from qinzhao at gcc dot gnu.org --- resolved in GCC13
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #14 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:afe6cea4489846aa8585f3c045d16cdaa08cc6cd commit r13-6379-gafe6cea4489846aa8585f3c045d16cdaa08cc6cd Author: Qing Zhao Date: Tue Feb 28 17:11:05 2023 + Fixing PR107411 This is a bug in tree-ssa-uninit.cc. When doing the following: /* Ignore the call to .DEFERRED_INIT that define the original var itself as the following case: temp = .DEFERRED_INIT (4, 2, âalt_reloc"); alt_reloc = temp; In order to avoid generating warning for the fake usage at alt_reloc = temp. */ We need to compare the var name inside the .DEFERRED_INIT call (the 3rd argument) and the name for the LHS variable. if they are the same, we will NOT report the warning. There is one issue when we get the name for the LHS variable. when the variable doesn't have a DECL_NAME (it's not a user declared variable, which is the case for this bug): _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); D.2389 = _1; The current checking just ignores this case, and still report the warning. The fix is very simple, when getting the name for the LHS variable, we should consider this case and come up with the name the same way as we construct the 3rd argument for the call to .DEFERRED_INIT (please refer to the routine "gimple_add_init_for_auto_var") PR middle-end/107411 gcc/ChangeLog: PR middle-end/107411 * gimplify.cc (gimple_add_init_for_auto_var): Use sprintf to replace xasprintf. * tree-ssa-uninit.cc (warn_uninit): Handle the case when the LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME. gcc/testsuite/ChangeLog: PR middle-end/107411 * g++.dg/pr107411.C: New test.
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #13 from rguenther at suse dot de --- On Thu, 16 Feb 2023, qing.zhao at oracle dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 > > --- Comment #8 from Qing Zhao --- > > On Feb 16, 2023, at 2:35 AM, rguenther at suse dot de > > wrote: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 > > > > --- Comment #7 from rguenther at suse dot de --- > > On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote: > > > > > > Hmm, I don't think so. So this is indeed expected behavior since the > > frontend IL doesn't have variable definitions with initializers but > > instead just (immediately following) assignments. > > Then, if that’s the case, it also is correct to add the .DEFERRED_INIT to them > during gimplification? Yes.
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #12 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #11) > (In reply to qinzhao from comment #10) > > the following patch fixed this issue: > > This would leak memory. thank you, I will fix the memory leak issue in the patch.
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- (In reply to qinzhao from comment #10) > the following patch fixed this issue: This would leak memory.
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #10 from qinzhao at gcc dot gnu.org ---
the following patch fixed this issue:
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index c555cf5cd50..eca727b010a 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
@@ -113,6 +113,18 @@ uninit_undefined_value_p (tree t)
return !get_no_uninit_warning (SSA_NAME_VAR (t));
}
+
+/* Get the name string for the VAR that defined with a call to .DEFERRED_INIT.
+ * Refer to routine gimple_add_init_for_auto_var. */
+static const char *
+get_var_name (tree var)
+{
+ const char *var_name_str
+= DECL_NAME (var) ? IDENTIFIER_POINTER (DECL_NAME (var))
+ : xasprintf ("D.%u", DECL_UID (var));
+ return var_name_str;
+}
+
/* Emit warnings for uninitialized variables. This is done in two passes.
The first pass notices real uses of SSA names with undefined values.
@@ -224,8 +236,6 @@ warn_uninit (opt_code opt, tree t, tree var, gimple
*context,
at alt_reloc = temp.
*/
tree lhs_var = NULL_TREE;
- tree lhs_var_name = NULL_TREE;
- const char *lhs_var_name_str = NULL;
/* Get the variable name from the 3rd argument of call. */
tree var_name = gimple_call_arg (var_def_stmt, 2);
@@ -239,11 +249,12 @@ warn_uninit (opt_code opt, tree t, tree var, gimple
*context,
else if (TREE_CODE (gimple_assign_lhs (context)) == SSA_NAME)
lhs_var = SSA_NAME_VAR (gimple_assign_lhs (context));
}
- if (lhs_var
- && (lhs_var_name = DECL_NAME (lhs_var))
- && (lhs_var_name_str = IDENTIFIER_POINTER (lhs_var_name))
- && (strcmp (lhs_var_name_str, var_name_str) == 0))
- return;
+ if (lhs_var)
+ {
+ const char *lhs_var_name_str = get_var_name (lhs_var);
+ if (strcmp (lhs_var_name_str, var_name_str) == 0)
+ return;
+ }
gcc_assert (var_name_str && var_def_stmt);
}
}
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #9 from qinzhao at gcc dot gnu.org --- it's a bug in tree-ssa-uninit.cc actually. when doing the following: /* Ignore the call to .DEFERRED_INIT that define the original var itself as the following case: temp = .DEFERRED_INIT (4, 2, “alt_reloc"); alt_reloc = temp; In order to avoid generating warning for the fake usage at alt_reloc = temp. */ we need to compare the var name inside the .DEFERRED_INIT call (the 3nd argument) and the name for the left side variable. if they are the same, we will NOT report the warning. there is one issue when we get the name for the left side variable. when the variable doesn't have a DECL_NAME (it's not a user declared variable, which is the case for this bug): > _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); > D.2389 = _1; (in the above example, D.2389 is a variable that doesn't have a DECL_NAME.) the current checking just ignores this case, and still report the warning. this is incorrect. The fix is very simple, when get the var name for the left side variable, we should consider this case and come up with the name the same way as we construct the 3rd argument for the call to .DEFERRED_INIT (please refer to the routine "gimple_add_init_for_auto_var")
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #8 from Qing Zhao --- > On Feb 16, 2023, at 2:35 AM, rguenther at suse dot de > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 > > --- Comment #7 from rguenther at suse dot de --- > On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote: > > > Hmm, I don't think so. So this is indeed expected behavior since the > frontend IL doesn't have variable definitions with initializers but > instead just (immediately following) assignments. Then, if that’s the case, it also is correct to add the .DEFERRED_INIT to them during gimplification?
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #7 from rguenther at suse dot de --- On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 > > --- Comment #6 from qinzhao at gcc dot gnu.org --- > (In reply to Richard Biener from comment #2) > > > > The gimplifier instead of > > > > _1 = t (); > > D.2389 = _1; > > e = > > _2 = *e; > > f (_2); > > > > produces > > > > _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); > > D.2389 = _1; > > e = .DEFERRED_INIT (8, 2, &"e"[0]); > > _2 = t (); > > D.2389 = _2; > > e = > > _3 = *e; > > f (_3); > > > > which is odd and sub-optimal at least. Doing such things makes us rely > > on DSE to elide the uninit "inits". > > actually, this is because, The simplifier sees the following IR from FE > (.original) > > const int D.2768; > const int & e; > < (void) (e = D.2768 = t ();, (const int &) ) >; > < f ((int) *e) >; > } > > i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first, > and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e" > and "D.2768". since it doesn't see any connections between these two > DECL_EXPRs > and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two > DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them. > > the best approach to resolve this issue is: > > if there is any connection between DECL_EXPR "D.2768","e" and their > initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then > during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them; > > my question is: in the current IR from C++ FE, is there any bit I can check to > make sure that the DECL_EXPR "D.2768" and "e" already have initialization > inside "CLEANUP_POINT_EXPR"? Hmm, I don't think so. So this is indeed expected behavior since the frontend IL doesn't have variable definitions with initializers but instead just (immediately following) assignments.
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > > The gimplifier instead of > > _1 = t (); > D.2389 = _1; > e = > _2 = *e; > f (_2); > > produces > > _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); > D.2389 = _1; > e = .DEFERRED_INIT (8, 2, &"e"[0]); > _2 = t (); > D.2389 = _2; > e = > _3 = *e; > f (_3); > > which is odd and sub-optimal at least. Doing such things makes us rely > on DSE to elide the uninit "inits". actually, this is because, The simplifier sees the following IR from FE (.original) const int D.2768; const int & e; <; <; } i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first, and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e" and "D.2768". since it doesn't see any connections between these two DECL_EXPRs and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them. the best approach to resolve this issue is: if there is any connection between DECL_EXPR "D.2768","e" and their initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them; my question is: in the current IR from C++ FE, is there any bit I can check to make sure that the DECL_EXPR "D.2768" and "e" already have initialization inside "CLEANUP_POINT_EXPR"?
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 Andrew Pinski changed: What|Removed |Added CC||trprince at synopsys dot com --- Comment #5 from Andrew Pinski --- *** Bug 108780 has been marked as a duplicate of this bug. ***
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 Andrew Pinski changed: What|Removed |Added CC||larsbj at gullik dot org --- Comment #4 from Andrew Pinski --- *** Bug 107793 has been marked as a duplicate of this bug. ***
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > > The gimplifier instead of > > _1 = t (); > D.2389 = _1; > e = > _2 = *e; > f (_2); > > produces > > _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); > D.2389 = _1; > e = .DEFERRED_INIT (8, 2, &"e"[0]); > _2 = t (); > D.2389 = _2; > e = > _3 = *e; > f (_3); > > which is odd and sub-optimal at least. Doing such things makes us rely > on DSE to elide the uninit "inits". Looks like that "_1 = t ()" was not treated as an initializer, therefore "_1" was identified as an uninitialized var. "e = " has the same issue. should "_1 = t ()" be treated as an initializer to _1?
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
Richard Biener changed:
What|Removed |Added
Blocks||24639
CC||qing.zhao at oracle dot com,
||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. reduced testcase:
> int t();
> void f(int);
>
> void j()
> {
> const int& e = t();
> f(e);
> }
>
> Someone who understands the uininit pass should look into this but the IR at
> that point we get is (with -fno-exceptions due to extra clobbers otherwise
> which don't make a difference):
> _1 = .DEFERRED_INIT (4, 2, &"D.2374"[0]);
> D.2374 = _1;
> e_6 = .DEFERRED_INIT (8, 2, &"e"[0]);
> _2 = t ();
> D.2374 = _2;
> e_9 =
> _3 = *e_9;
> f (_3);
> D.2374 ={v} {CLOBBER(eol)};
>
> There is no read from D.2374 in the call to t at all and then we do a full
> write after the call.
We diagnose the
D.2374 = _1;
store which uses uninitialized _1. The FE emits
<;
<;
note that without -ftrivial-auto-var-init=zero we see
:
_6 = t ();
:
_1 = _6;
D.2389 = _1;
e_8 =
_2 = *e_8;
f (_2);
:
D.2389 ={v} {CLOBBER(eol)};
return;
:
:
D.2389 ={v} {CLOBBER(eol)};
resx 1
while with the flag we have
:
_1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
D.2389 = _1;
e_7 = .DEFERRED_INIT (8, 2, &"e"[0]);
_9 = t ();
:
_2 = _9;
D.2389 = _2;
e_11 =
_3 = *e_11;
f (_3);
:
D.2389 ={v} {CLOBBER(eol)};
return;
:
:
D.2389 ={v} {CLOBBER(eol)};
resx 1
The gimplifier instead of
_1 = t ();
D.2389 = _1;
e =
_2 = *e;
f (_2);
produces
_1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
D.2389 = _1;
e = .DEFERRED_INIT (8, 2, &"e"[0]);
_2 = t ();
D.2389 = _2;
e =
_3 = *e;
f (_3);
which is odd and sub-optimal at least. Doing such things makes us rely
on DSE to elide the uninit "inits".
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-10-26
--- Comment #1 from Andrew Pinski ---
Confirmed. reduced testcase:
int t();
void f(int);
void j()
{
const int& e = t();
f(e);
}
Someone who understands the uininit pass should look into this but the IR at
that point we get is (with -fno-exceptions due to extra clobbers otherwise
which don't make a difference):
_1 = .DEFERRED_INIT (4, 2, &"D.2374"[0]);
D.2374 = _1;
e_6 = .DEFERRED_INIT (8, 2, &"e"[0]);
_2 = t ();
D.2374 = _2;
e_9 =
_3 = *e_9;
f (_3);
D.2374 ={v} {CLOBBER(eol)};
There is no read from D.2374 in the call to t at all and then we do a full
write after the call.
