Re: Is it time to take the middle-end stringop/array warnings out of -Wall?

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++