On 5/22/26 19:09, Siddhesh Poyarekar 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.
Not to throw cold water on the party, but that particular warning
infrastructure's past performance has been dismal in the presence of
better range info. I'm afraid better range info from prange replacing
pointer_query will not achieve the desired result... In fact I would be
very surprised if it isn't worse. (Sorry Sid :-) When ranger was first
enabled, the warnings got far worse which I took flak for from the
author... for producing more accurate ranges no less. Kudos for being
optimistic tho.. you never know! :-)
however, it provides a path forward where we have something
understandable and dependable to build on for at least that portion of
the code... But it still requires someone to focus on the actual
warning decisions themselves. I expect that to not be too onerous once
pointer_query is gone, but it does require an interested body.
My impression is the primary culprit is the data accessing components
and following decisions based on expected unknowns. I believe the code
was frequently checking for sentinels where max-value indicated
"unknown", and no warning would be issued... More precise ranges often
removed some of the least significant bits from the upper bound, This
would then send the warning code into unwelcome territory because the
unknown sentinel wasn't triggered.
Maybe an experiment to adjust ranges that are "close" to max_value into
max_value might help the problem in the near term:-)
My undoubtedly unpopular 2 cents :-) I'd be shocked if prange was a
quick fix for this.
Andrew
