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 881323858C3A; Fri,  8 Dec 2023 07:56:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 881323858C3A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1702022164;
	bh=xe+xt5ULCUel2uygvash8X0ibt5EJUNbrsmmi1WkW7s=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=JS05dbkq+ao/JgXBltGPY5HQTGlH1Vm6kmh7KbSn3I+bYFGgRWAfp65L420RPU5WY
	 LjvUMosB/LiyUwLIdDQn5y1izrCpoFK//hmRvBUP6D4sp1qj0JNnp03KJ8QXCbFJKi
	 YyjLGWMD2M8x4M6PKWt5l1157sKllGuwB/Iubg0U=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/112909] [14 Regression] glibc -Wuninitialized build
 failure for i686-gnu
Date: Fri, 08 Dec 2023 07:56:04 +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: 14.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
 assigned_to
Message-ID: <bug-112909-4-fMjcDHrfg8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112909-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112909-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=3D112909

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2023-12-08
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot =
gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  We diagnose

_hurd_setup_sighandler ()
{
if (ss->context)
  {
...
<bb5>
scp_67(ab) =3D PHI <scp_98(D)(4), scp_68(ab)(6)>
_105 =3D setjmp ();
if (_105 =3D=3D 0)
  scp_202 =3D scp_67(ab);


and scp_98(D) is not initialized from function start but only eventually
via the abnormal path (note how the CFG is sligthly incorrect since the
abnormal return wouldn't enter setjmp again and also not really bypass
the _105 =3D=3D 0 check).

I think the copy we diagnose is a spurious use we just fail to propagate,
but scp_67 is really used on an abnormal edge in a PHI (in the abnormal
dispatcher).

I can't convince myself right now that it's always safe to propagate
the copy (scp_202 is single-use with a use in a PHI argument not on
an abnormal edge).

The copy appears from thread2 which copies along the 9->10 edge, turning

 # scp_69(ab) =3D PHI <scp_98(D)(3), scp_67(ab)(9), scp_67(ab)(8)>

into a copy there.

But we can make uninit analysis look through reg-reg copies, ignoring
unguarded uninit uses in those.=