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

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