From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DB56D385840D; Tue, 30 Jan 2024 11:11:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB56D385840D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706613099; bh=gQMxEEsaX5KLP5YH5uMDJ3S01iwQhl/54E8QG7PE3fA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=khVaff6JRE66XqruZQYhzVi42ROPYCwvSPZpvJYjyZOkNCU2BiNtDoD+qmTcEl+0m IvfpTLsabsMkmEdzirckh26Mxw4GFEIQ2ytj8sgELgVGcDPN9FMaIJ3EGJImJTJkEu JiEYOvMbuauJhgxpF1x1HPAFZWEbKnxSCn0IysjM= From: "stefan at bytereef dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow) Date: Tue, 30 Jan 2024 11:11:36 +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: 14.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: stefan at bytereef dot 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113664 --- Comment #5 from Stefan Krah --- > So the diagnostic messages leave a lot to be desired but in the end > they point to a problem in your code which is a guard against a NULL 's'. Hmm, the real code is used to print floating point numbers and integers. Integers get dot=3D=3DNULL. It is fine (and desired!) in that case to optim= ize away the if clause. As far as I can see, it is compliant with the C standard. Even with -fno-strict-overflow one could make the case that the warning is strange. If "s" wraps around, the allocated output string is too small, and you have bigger problems. It is impossible for gcc to detect whether the string size is sufficient, so IMHO it should not warn. In essence, since gcc-10 (12?) idioms that were warning-free for 10 years tend to receive false positive warnings now. This also applies to -Warray-bounds. I think the Linux kernel disables at least -Warray-bounds and -Wmaybe-uninitialized. I think this is becoming a problem, because most projects do not report false positives but just silently disable the warnings.=