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 709D43858D35; Thu, 20 Jan 2022 09:20:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 709D43858D35
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102650] [12 Regression] Dead Code Elimination
 Regression at -O3 (trunk vs 11.2.0)
Date: Thu, 20 Jan 2022 09:20:14 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102650-4-uhSjpLYil8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102650-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102650-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jan 2022 09:20:14 -0000

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Actually e will not be used uninitialized

    for (; d < 1; d++)
        e =3D f + a;

will initialize it since d is zero and its value will be 4.  But jump
threading isolates the case where we would access e uninitialized.
So yes, it does seem worth doing that but maybe only on isolated paths
(to not defeat uninit diagnostics and also to remove spurious uninit
diagnostics).  The situation isn't easily visible from the threader
itself and the question is how much GCC itself will expose unconditional
uninit uses (there are some bugs around ifcombine doing that) so it's
prone to producing wrong-code as well.

That said, we probably have to live with this regression for GCC 12 and
could look into sanitizing our undef behavior for GCC 13 somehow.=