From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D79AB3857C5D; Fri, 10 Dec 2021 22:10:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D79AB3857C5D From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread Date: Fri, 10 Dec 2021 22:10:51 +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: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jason 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: cc see_also 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: Fri, 10 Dec 2021 22:10:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103483 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=3D102958 --- Comment #12 from Jason Merrill --- (In reply to Martin Sebor from comment #3) > GCC 11 doesn't warn because it's unable to determine the range of the last > memcpy() argument. Thanks to the Ranger improvements GCC 12 is able to do > better. In some cases this should improve the S/N ratio of the middle end > diagnostics that depend on ranges. Unfortunately, in others like this one > where other optimizations are disabled it can make things worse. It seems to me that if we don't warn when we have no information about the range of the argument, we also shouldn't warn when we have only path-depend= ent information about the range of the argument. The testcase in comment #0 is definitely dubious for using an unbounded int= d to index into a bounded array, so let's consider a more reasonable C testca= se derived from PR102958 for which there is no missed-optimization issue. char *sink; /* Definitions unavailable to optimization. */ int secret_strlen (const char *p); void secret_memcpy (char *, const char *, int); inline void copy(const char *p) { int L =3D secret_strlen (p);=20=20 if (L < 16) /* disabling this branch prevents the warning */ secret_memcpy (sink, p, L); else __builtin_memcpy (sink, p, L); } void f() { copy ("12"); // bogus warning } At the __builtin_memcpy we have a constant string "12" and an unknown lengt= h L, and we try to copy L bytes of the constant string into a buffer. We do thi= s in different ways depending on whether L is less than 16; on the latter path we __builtin_memcpy L bytes from the constant string into the buffer. And so -Wstringop-overread warns that we're reading 16 or more bytes from a 3-byte string. But we still have no basis for concluding that L is actually >=3D 16, we do= n't know its value at all. That this path is only taken for L >=3D 16 doesn't = tell us whether it's actually possible that L >=3D 16; we can't assume that just because we don't know the value of len, it could therefore have any value, = and so all branches are reachable for a specific string argument. We're able to propagate one constant value, and warning because an unknown value might be incompatible with the known value. And with the recent chan= ges we're able to do more of this asymmetric constant propagation. Perhaps it would be useful to have an optional mode for these (and other) warnings that does assume that all branches are reachable, but it can't be = the default. -Wmaybe-stringop-overread? -Wstringop-overread=3Dmaybe? My testcase above has given a false positive since GCC 8. I'm nervous about people adding __builtin_unreachables to suppress these warnings; forced assumptions can be big foot-guns.=