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 9532D3857B86; Wed, 31 Aug 2022 06:52:19 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9532D3857B86
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1661928739;
	bh=rHHNX9sCFo8o3MY1yl4GjimHK1CFfIaTfeXq0EFTT5Q=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=iybOAon6lCFuGzJEm27LXV/EkkGpb+6RQ0eTbx2vwjbruuVJCTs98pjHpVzf4+p2F
	 5LfFx+rulFNqty4NBfgLBdRCB+jHCFn9pTr+YrxpNcshskL/ZulASlqA/vMOQ/DwUh
	 iop9qTCoPvQnnz7tuz9LakCRdmWLq1MT8GBXjfHg=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/73550] Another wrong -Wmaybe-uninitialized
 warning in switch statement
Date: Wed, 31 Aug 2022 06:52:18 +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: 7.0
X-Bugzilla-Keywords: diagnostic, 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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-73550-4-UaM1Qfs2ml@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-73550-4@http.gcc.gnu.org/bugzilla/>
References: <bug-73550-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=3D73550

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Another thing we have is that with

After normalization [USE]:
        fp_5 (a.3_4, b.2_3);
  is conditional on:
        ((_27 & 20500) AND (NOT (_26 !=3D 0)) AND (NOT (_20 > 14)))

and

After normalization [DEF]:
        fp_5 =3D PHI <fun1(6), fun3(24), fp_11(D)(21), fun2(3), fun3(26)>
  is conditional on:
        ((code_9(D) =3D=3D 2))
        OR ((code_9(D) <=3D 4) AND (code_9(D) >=3D 3))
        OR ((code_9(D) =3D=3D 1))
        OR ((code_9(D) =3D=3D 12))
        OR ((code_9(D) <=3D 14) AND (code_9(D) >=3D 13))
        OR ((code_9(D) =3D=3D 11))

the negated _26 !=3D 0 predicate is not "normalized", it's defined as

  _20 =3D (unsigned int) code_9(D);
...
  _27 =3D 1 << _20;
  _26 =3D _27 & 480;

so ultimatively switch lowering lowers the second switch statement which
confuses us greatly here.  OTOH without switch lowering we'd fail to
process the use predicate because it's reached by multiple case
labels.

Solving this case fully is going to be interesting, but I have some more
incremental improvements here.=