On Fri, May 22, 2026 at 4:09 PM Siddhesh Poyarekar <[email protected]> wrote: > > On 22/05/2026 18:23, Jason Merrill wrote: > > > 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). > > I feel like we only sometimes see the true positive reports (where > either the warning was introduced the first time, or the developer > hasn't fully understood that it was a true positive before reporting it, > which may not happen that often) whereas we always get to see false > positive reports since they're essentially bugs in the compiler, thus > amplifying its effect. I don't want to make it sound like it's not > frustrating because it absolutely is, especially the way they've been > designed but there's an intrinsic bias in how we tend to see them. > > > > > 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 <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. > I'm the more recent of those people and unfortunately I haven't been > able to spend enough time on it beyond the odd hack, sorry :/ But yeah, > consider me motivated because as much as the code currently frustrates > me, I see real value in the core idea to see it reinstated if we go the > way of dropping it from -Wall. > > I do think though that adding it to -Wextra is pointless and maybe just > keeping them independent is sufficient. We have projects like the > OpenSSF C/C++ hardening guide[1] that should plug these options to > people who would like to see these warnings. That and maybe enable them > in -fhardened, although currently that flag only flips options that > affect codegen (IIRC). > > Could we however wait until Andrew MacLeod works through porting the > pointer-query stuff to pranges and then decide? It won't bring the > false positives down to zero, but maybe improve range visibility enough > (and maybe Andrew cleans more things up as he works on it!) for them to > be less problematic than what they are today.
Unless these will improve the devirtualization choices (which I have my doubts they will), there will still need to have something done separately for those. And I don't see anyone working on that. The work that is being mentioned might bring down the cases that were showing up before GCC 16 but I am still not holding my breath on that either. The situation got much worse in GCC 16 due to the devirtualization improvements. Maybe there is a way to improve those choices in the first place. (I have not looked into seeing if it could see size based choices or something like that yet). Thanks, Drea > > Thanks, > Sid > > [1] > https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++
