From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C08103851C19; Tue, 22 Jun 2021 15:27:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C08103851C19 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow Date: Tue, 22 Jun 2021 15:27: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: 11.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WONTFIX 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, 22 Jun 2021 15:27:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101134 --- Comment #5 from Martin Sebor --- It wouldn't be right to change the wording of just one warning because the problem applies to all flow based diagnostics. They all depend on various optimizations that propagate constants, add or remove tests, and change the control flow graph. A statement that in the source code is conditional on = the values of various parameters might in the intermediate representation appear unconditional with constants as a result, even be unconditionally invalid b= ut unreachable. This is true at function scope as well as across function call boundaries thanks to inlining. Changing the wording for all of them to try= to somehow reflect this wouldn't help because then all instances of them all w= ould have to use the new form. -Wuninitialized and -Wmaybe-uninitialized aren't substantially different in this. The latter is unique only in that it diagnoses arguments of PHI node= s, which are the results of conditional expressions. This property is describ= ed by the following sentence in the manual: "...if there exists a path from the function entry to a use of the object t= hat is initialized, but there exist some other paths for which the object is not initialized, the compiler emits a warning if it cannot prove the uninitiali= zed paths are not executed at run time." This is only roughly what happens but there are many instances of -Wuninitialized that could be described using the same sentence, even thoug= h it doesn't consider PHI nodes. If we do introduce a similar distinction in ot= her warnings like -Wstringop-overflow it will be on top of the instances already issued by them, not a subset of them. This is a general property of all flow based warnings in GCC except those emitted by the static analyzer which doesn't depend on the same optimizatio= ns (only a very small subset of them). All warnings (flow based or otherwise, including those issued by the analyzer) should always be viewed as document= ed, i.e., as "messages that report constructions that are not inherently errone= ous but that are risky or suggest there may have been an error."=