From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D629F38515DC; Tue, 30 Mar 2021 07:10:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D629F38515DC From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/43361] missing uninitialized warning without optimization (-O0) (PHI in always_executed basic block) Date: Tue, 30 Mar 2021 07:10:41 +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: 4.5.0 X-Bugzilla-Keywords: diagnostic 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: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 07:10:42 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D43361 --- Comment #15 from Richard Biener --- (In reply to Martin Sebor from comment #14) > Reconfirmed with GCC 11 and the C test case below: >=20 > void f (int); >=20 > int main () { > int i; > int array[10]; > for (; i<10; ++i) { // no warning > f (i); // no warning > array [i] =3D i; // no warning, really hurts > } > } So what's going "wrong" here is that we figure the BB with the i<10 check post-dominates the entry block and thus is always executed. But when doing warn_uninit on the SSA var we do not consider the value on the always-executed path from entry (which is uninitialized i_3(D)). That's for the early pass, the late pass doesn't run at -O0. Note since we walk BBs in index order which 'i' we warn for is probably random, I think we'll only warn once since we set TREE_NO_WARNING on the underlying decl of the SSA name (that's probably misguided - different SSA defs can have different uninit state). It might be possible to populate possibly_undefined_names in the BB walk by visiting PHIs and considering fallthru entries being taken to have this work out without major restructuring of the pass (a lattice of "undefinedne= ss" would probably be more to the point).=