On Wed, May 20, 2026 at 7:30 AM Jonathan Wakely via Gcc <[email protected]> wrote: > > The false positive rate has been unacceptably high for years, with > very little progress on reducing that rate.
With the introduction of predictively devirtualization that can include more than one candidate, the warnings are way too late. and have become useless. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122197 is one example (it blocks a few others too). So either we start marking whole sections not to warn (while inlining) or we disable the warnings. Since I don't see an easy solution to mark while inining, I vote for removing them from -Wall (and NOT adding them to -Wextra). Thanks, Andrea > > It's true that often the false positives reveal a missed optimization > opportunity in the compiler, and so there's a small benefit to GCC > from finding those missed optimizations, and eventually that trickles > down to users when some future version of GCC optimizes better. But > that indirect, delayed benefit is a big negative for end users today, > when they compile their code and get those warnings. A wall of > warnings about accessing offset > 0xfffffffffffffffffffffffffffffffffffffff4 in an array of 2 elements > is just garbage and makes GCC look bad. > > It seems that we're using "lie to the user about them having buffer > overflow bugs" as a proxy for "please show us your code so we can > optimize it better". That's a terrible policy. > > Despite repeated requests, the warnings still lie. They tell users > there *is* an overflow, when what they should say is that there might > be, for some specific control flow which might actually be unreachable > or in dead code. We should not be lying to users with -Wall. > > The warnings **are not actionable**. They are usually the result of > complex transformations and reordering by the optimizers, but the > warning gives no indication of that. It just says "overflow on this > line", without explaining that the compiler is assuming some sequence > of conditions which have to hold before the "bug" could happen. If we > had more context to see that the "bug" depends on some particular set > of inputs, the user could verify that those inputs are impossible, or > could add assertions/assumptions to enforce that they really are > impossible. But because the warnings don't give that context, only > half a dozen people in the world are qualified to go through the > optimized gimple dumps to track down why the compiler seems to be > smoking crack. What is a normal user (or even somebody like me who's > been working on GCC for more than 20 years) supposed to do with a > typical -Wstringop-overflow warning? > > Twice this week we've made improvements to libstdc++ which cause g++ > testsuite regressions and even bootstrap failures (apparently gccrs > and cobol are both currently broken thanks to libstdc++ changes). > > This is a massive waste of time for a large number of people who are > unable to do anything about the false positives. Only a handful of GCC > devs are able to figure out why the false positive comes from and do > anything about it, for the rest of us, it's just an ongoing source of > frustration. > > Can we please admit that those warnings do not have a good enough > signal-to-noise ratio to be in -Wall? Or can the people who want to > keep them be auto-ASSIGNED all related bugs, so that everybody else > can focus on other things? Currently the burden of dealing with these > false positives is on people working on unrelated parts of GCC, and > even worse, on end users.
