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

On 20/05/2026 13:18, Andrew Pinski via Gcc wrote:
> On Wed, May 20, 2026 at 7:30 AM Jonathan Wakely via Gcc <[email protected]> wrote:
>>
>> The false positive rate has been unacceptably high for years, with
>> very little progress on reducing that rate.

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.

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

The middle end bounds warnings aren't the only ones that struggle with 
this problem;  objsz has similar issues and we have hacks to accommodate 
for some of it, mainly because it directly affects codegen.  We still 
have the ugly early_objsz hack that doesn't quite work and needs a real 
solution to recognize subobjects.

Thanks,
Sid