The false positive rate has been unacceptably high for years, with very little progress on reducing that rate.
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.
