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.
Thanks,
Sid
[1]
https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++
