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. > 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. > > Thanks, > Sid >
