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

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