From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3C5FA3858D3C; Tue, 20 Jun 2023 08:38:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C5FA3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687250330; bh=58SV5CrlWMnZ9zmUG33mfhGIMigB5WJCGg5ZzmL5Qwg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iX1gI+Hr9s5Ec6lOq5n0VxrNtCdtFe68L/gOszDIGHsOONbQa5sNF5lnocfiTEupF hfAbDbIppF/rz/OgiyFrcX82mMQgZZ0UYAc4gy6/r7eNQfPRTQZf21fSl3PRuaPhwJ mgFQF3W1XBT/E6UzbvV1QIds9b76QVK1mxFUCR9o= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1. Date: Tue, 20 Jun 2023 08:38:27 +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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh 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: 13.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110228 --- Comment #17 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #4) > Phiopt does this: > ``` > v_13 =3D=3D 1 ? 1 : LookupFlags_6 > Matching expression match.pd:1990, gimple-match-5.cc:23 > Matching expression match.pd:1990, gimple-match-5.cc:23 > Matching expression match.pd:2479, gimple-match-4.cc:35 > Matching expression match.pd:2482, gimple-match-3.cc:66 > Matching expression match.pd:2489, gimple-match-2.cc:58 > Matching expression match.pd:1947, gimple-match-7.cc:20 > Applying pattern match.pd:4742, gimple-match-7.cc:15326 > Folded into the sequence: > _17 =3D v_13 =3D=3D 1; > _18 =3D LookupFlags_6 | _17; > Removing basic block 5 > ;; basic block 5, loop depth 1 > ;; pred: 4 > ;; succ: 6 > ``` > As zero_one_valued_p returns true for LookupFlags_6 because > tree_nonzero_bits/get_nonzero_bits returns 1 for it. >=20 > So it is ranger in the end that returns that it has a nonzero bits of 1. > Which is completely wrong as LookupFlags_6 is defined by: > # LookupFlags_6 =3D PHI >=20 >=20 > Which has an uninitialized variable in it which is not defined at what its > value would be .... BTW, it doesn't seem ranger would be involved here at all, since this bug happens with -O1, and evrp nor VRP* run at this level. The only other way ranger could be involved at -O1 is through DOM threading's use of ranger, b= ut phiopt1 from which your dump above comes from, runs before DOM. I realize further downthread y'all conclude this is an unitialized issue, b= ut I'm just trying to understand how ranger could have been involved. FWIW, there are other passes which set global nonzero bits at -O1, most not= ably CCP. Theoretically any pass which calls set_range_info() or set_nonzero_bi= ts() would alter everyone's view of a range (strlen pass, PRE, DOM, sprintf, CCP, etc). And way down on the list of likely scenarios is fold_range() being called w= ith a global query object. This would get ranger involved in folding something with known global values (no additional lookups), but it's unlikely. You probably got a nonzero bits from some other pass.=