From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 88C883846074; Wed, 31 Mar 2021 21:11:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88C883846074 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL Date: Wed, 31 Mar 2021 21:11:33 +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: 7.0 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: target_milestone bug_status resolution cc cf_known_to_work cf_known_to_fail 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: Wed, 31 Mar 2021 21:11:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71699 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |9.0 Status|NEW |RESOLVED Resolution|--- |FIXED CC| |msebor at gcc dot gnu.org Known to work| |9.3.0 Known to fail| |7.3.0, 8.3.0 --- Comment #13 from Martin Sebor --- At -O1 and above the warning has disappeared with r263662 (GCC 9.0.0 201808= 20). It's still on trunk with -O0 (and with -Og) not with higher optimization levels. But I'm not sure I see this as a problem. The test case assigns an uninitialized variable for no apparent reason and expects the assignment to= be eliminated. That does happen but only with optimization. The warning could probably be enhanced to figure this out by essentially implementing the same logic as the optimization does but that seems like going too far. With so = many open bugs against -Wuninitialized of higher priority with no progress for a decade or more I'm going to resolve this one as fixed.=