On Fri, May 22, 2026 at 5:26 PM Jonathan Wakely via Gcc <[email protected]> wrote:
> On Fri, 22 May 2026, 21:03 Siddhesh Poyarekar, <[email protected]> > wrote: > > > On 20/05/2026 13:18, Andrew Pinski via Gcc wrote: > > > 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. > > > > Is the false positive rate so bad that it reduces the the utility of the > > true positives that potentially get caught through -Wall? It's not like > > all code is perfect now and that the true positives are no longer > > valuable enough to keep in -Wall. > > I don't know, I never see any true positives. I waste a lot of time trying > to suppress or work around false negatives (e.g. several hours per day for > several days this week, just on the latest set of regressions caused by > these warnings). > > > > 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). > > Alternatively, could this also be an indication that we easily let > > transformations lose original program context and that when a pass does > > this (e.g. address aliasing), we should have it try harder retain the > > lost information somehow? > > Maybe, but we should fix *that* before enabling these warnings. And we've > had many years to do it, and not done it. > And over the years we've talked about three or four different people at Red Hat working on improving the situation, without much to show for it, though Qing's new -fdiagnostics-show-context sounds like a great step. I'm all in favor of improving the SNR of these warnings. If moving them out of -Wall motivates someone to work on that, great, and we could certainly move them back if they improve. Jason > The middle end bounds warnings aren't the only ones that struggle with > > this problem; objsz has similar issues and we have hacks to accommodate > > for some of it, mainly because it directly affects codegen. We still > > have the ugly early_objsz hack that doesn't quite work and needs a real > > solution to recognize subobjects. >
