public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread Date: Sat, 11 Dec 2021 00:56:56 +0000 [thread overview] Message-ID: <bug-103483-4-1ILJjBXZ3h@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103483-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 --- Comment #13 from Martin Sebor <msebor at gcc dot gnu.org> --- The warning for the test case in comment #12 isn't directly related to ranges: it's issued simply because the invalid statement is in the IL and not eliminated by DCE (the secret functions don't let it). Similar warnings have been issued in equivalent situations for constants propagated through inlining. Here's one for -Wnonnull (issued since GCC 7): char *sink; __attribute__ ((noinline, noipa)) int null_safe_strlen (const char *p) { return p ?__builtin_strlen (p) : 0; } static inline void copy (const char *p) { int N = null_safe_strlen (p); if (N) /* disabling this branch prevents the warning */ __builtin_memcpy (sink, p, N); else *sink = 0; } void f() { copy (0); // bogus warning } In function ‘copy’, inlined from ‘f’ at z.c:17:3: z.c:10:5: warning: argument 2 null where non-null expected [-Wnonnull] 10 | __builtin_memcpy (sink, p, N); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ z.c:10:5: note: in a call to built-in function ‘__builtin_memcpy’ All GCC warnings trigger on invalid statements in the IL, regardless of whether the statements are in reality reachable. This includes all warnings that consider data flow like -Wnonnull, -Warray-bounds, and -Wformat-overflow among many others. Ranges just let them find more invalid statements than constants alone would. This is also the most basic reason why the -Wstringop- warnings are issued for the test case in comment #0 or in or PR 103332. Two changes are behind the spate of recent bug reports about these warnings for std::string: 1) in GCC 11 we enabled a subset of warnings for code inlined from system headers, and 2) in GCC 12 thanks to Ranger the range info has become more accurate and tighter (larger lower bounds and smaller upper bounds). Before Jonathan suppressed the warnings in r12-5874 in libstdc++, Andrew MacLeod suggested temporarily (for GCC 12) disabling the context-sensitive Ranger info and going back to global ranges, until we have a better way of dealing with the increased accuracy. That would reduce the number of false positives but it would also correspondingly increase false negatives, and so defeat one of the main reasons for Ranger: better quality warnings. It might still be a compromise to consider if the problem turns out to be sufficiently severe and if we can think of a way of to handle the ranges better in the future. But with the libstdc++ suppression I'm not convinced the problem is severe enough anymore. And I also can't think of a solution that would let us re-enable Ranger for warnings in the future. Nothing I've tried so far has showed much promise, and neither seems anything anyone has suggested. Independently, I have been thinking about adding -Wmaybe- forms of some of these warnings analogous to -Wmaybe-uninitialized (or corresponding levels), to diagnose conditional problems as in: char a[4], b[8]; void f (int i) { __builtin_memset (i ? a : b, 0, 7); // okay for b, overflow for a: thus "may overflow a" } but I have not been considering disabling the existing warnings (or removing it from -Wall) and issuing them only under the new option or some new level. That would in my mind be a drastic step back.
next prev parent reply other threads:[~2021-12-11 0:56 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-30 4:27 [Bug c++/103483] New: constexpr basic_string " john at mcfarlane dot name 2021-11-30 4:39 ` [Bug c++/103483] context-sensitive ranges change " pinskia at gcc dot gnu.org 2021-11-30 12:11 ` redi at gcc dot gnu.org 2021-11-30 17:56 ` [Bug middle-end/103483] " msebor at gcc dot gnu.org 2021-11-30 18:13 ` msebor at gcc dot gnu.org 2021-11-30 22:33 ` john at mcfarlane dot name 2021-12-01 16:38 ` aldyh at gcc dot gnu.org 2021-12-01 16:53 ` redi at gcc dot gnu.org 2021-12-01 23:38 ` pinskia at gcc dot gnu.org 2021-12-01 23:44 ` pinskia at gcc dot gnu.org 2021-12-02 22:14 ` msebor at gcc dot gnu.org 2021-12-09 23:24 ` cvs-commit at gcc dot gnu.org 2021-12-10 22:10 ` jason at gcc dot gnu.org 2021-12-11 0:56 ` msebor at gcc dot gnu.org [this message] 2021-12-11 22:43 ` jason at gcc dot gnu.org 2022-01-17 22:44 ` [Bug middle-end/103483] [12 regression] " jason at gcc dot gnu.org 2022-01-17 23:10 ` amacleod at redhat dot com 2022-01-18 0:47 ` msebor at gcc dot gnu.org 2022-01-28 2:02 ` pinskia at gcc dot gnu.org 2022-01-28 5:03 ` jason at gcc dot gnu.org 2022-01-28 6:38 ` law at gcc dot gnu.org 2022-01-28 7:48 ` redi at gcc dot gnu.org 2022-01-28 15:23 ` law at gcc dot gnu.org 2022-03-09 14:11 ` rguenth at gcc dot gnu.org 2022-03-14 23:58 ` msebor at gcc dot gnu.org 2022-05-06 8:32 ` [Bug middle-end/103483] [12/13 " jakub at gcc dot gnu.org 2022-10-19 9:43 ` rguenth at gcc dot gnu.org 2023-05-08 12:23 ` [Bug middle-end/103483] [12/13/14 " rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-103483-4-1ILJjBXZ3h@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).