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

On Fri, May 22, 2026 at 07:09:23PM -0400, 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

I have to disagree with that, unless you mean that the bug is the flawed
design of most of the middle-end warnings.  In some cases sure, the compiler
could have known some code is dead and optimize it away, but in most cases
the compiler actually can't know it is dead.

The flaw is that when the compiler knows nothing about a range (i.e.
VARYING), it doesn't emit these warnings (because then it would warn all the
time), but as soon as it knows for whatever reason that one value (or some
small set of those) is not possible, it is no longer VARYING range and the
middle-end warning code thinks that in that case all other values need to be
somehow possible and warns.  The worst thing is that it doesn't have to be
even in what the user wrote, it is possible the code just calls some otrher
function and that function has a special case for whatever reason and
happens to be inlined.  Or the compiler decided to jump thread something.
I don't see where you see a missed optimization in those cases generally.
The middle-end warnings simply emit more false positives when the range
information improves.

The complication is that some of the middle-end warnings are sometimes
emitted very early and in that case they are fairly reliable (I think e.g.
-Warray-bounds is sometimes diagnosed long before IPA), but at other times
late and after IPA and especially after jump threading I'm afraid it is
mostly about false positives.
Other warnings, like -Wnull-dereference, seems to be useless completely,
perhaps with the exception of most trivial cases before any optimizations
happen.  The false positive rate is huge, and when a NULL pointer is
dereferenced at runtime, it is very easy to fix it.

	Jakub