From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 5F4883858C60; Wed, 15 Feb 2023 19:21:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5F4883858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676488902;
	bh=cFXyJHiZgHFQ65+0n4FvVEbuhgOX4cKRFcTDZCt1RSk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=lPO6NueQkG74OaiZr9KC6bh8dlFKTtYttTgMVVKrNShG+7G7dCrObPGLS1pNyao4l
	 Fi96oOzswwd12d7PUH1Ca3x9vnLGVSXqOBnk4Znui5pZIm2bc6Lwixrk+x10MYI92S
	 IVFNfxVYccE/6/JP1booz5dZgTD7h0OAVvv5eluU=
From: "qinzhao at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/107411] trivial-auto-var-init=zero invalid
 uninitialized variable warning
Date: Wed, 15 Feb 2023 19:21:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: qinzhao at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107411-4-3jFI2bQD6S@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107411-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107411-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
>=20
> The gimplifier instead of
>=20
>       _1 =3D t ();
>       D.2389 =3D _1;
>       e =3D &D.2389;
>       _2 =3D *e;
>       f (_2);
>=20
> produces
>=20
>       _1 =3D .DEFERRED_INIT (4, 2, &"D.2389"[0]);
>       D.2389 =3D _1;
>       e =3D .DEFERRED_INIT (8, 2, &"e"[0]);
>       _2 =3D t ();
>       D.2389 =3D _2;
>       e =3D &D.2389;
>       _3 =3D *e;
>       f (_3);
>=20
> 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;
  <<cleanup_point <<< Unknown tree: expr_stmt
    (void) (e =3D D.2768 =3D t ();, (const int &) &D.2768;) >>>>>;
  <<cleanup_point <<< Unknown tree: expr_stmt
    f ((int) *e) >>>>>;
}

i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization firs=
t,
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_E=
XPRs
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, th=
en
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"?=