On 5/22/2026 8:36 PM, Andrew MacLeod via Gcc wrote:
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! :-)
IIRC what happened was when the ranges were completely unknown those
diagnostic analysis wouldn't trigger. Once Ranger started providing
ranges, the diagnostic code would simply have more cases to analyze,
some of which it couldn't produce a tight enough range to avoid bogus
diagnostics.
The other problem is those diagnostics had a ton of heuristics to try
and cut down false positives; my hope was that over time we'd see enough
commonality that a real path forward on either the optimization
problems, Ranger bits or the diagnostic analysis itself would present
itself. I'm not sure Martin ever saw things that way and once I
departed Red Hat I didn't have an kind of mandate to focus on those
problems or to push Martin in this direction.
These warnings feel a lot more problematical than the uninit warnings.
Probably because uninit is a simpler problem. A false positive is
generally due to a missed optimization resulting in an infeasible path
in the CFG. For the array indexing, oob reads/writes we're talking
about we can get confused by aliases, vectorization, etc etc. There's
just a lot more that can go wrong than just an infeasible path in the CFG.
Ultimately it's all just a long way of saying that while I see value in
these diagnostics, I think we need to acknowledge that the situation
isn't improving and they're causing significant issues.
Jeff
