Am Freitag, dem 22.05.2026 um 21:53 -0600 schrieb Jeffrey Law via Gcc: > > 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.
FWIW, as a C user I think the warnings are useful and there are less false positives now than there were in the past. With recent GCC I build my projects with -Werror -Wall -Wextra with no major issue and "maybe uninitialized" is still the one with the most false positives (which are easy to fix though and also -fanalyzer produces even more false positives). Having tried to understand some of the middle-end warning code to fix some bugs, I would say redesigning it from scratch might still be a good idea ;-) I also think a much more systematic approach to dealing with warnings related to undefined behavior is needed (and possible). IMHO one should unify this with the sanitizers and add instrumentation in the FE for language-level UB that is then transformed into either __builtin_trap, __builtin_unreachable, and optionally emitting a warning in the middle-end when not optimizing depending on flags and heuristics. Then there would also be a synergy between aggressive optimization and diagnostics and trapping sanitizers. Optimizations that either hide preconditions or add speculative code paths could turn off the instrumentations if this is necessary to avoid false positives, which should be more easy when those are explicitely present in the IR as instrumentation. The traditional diagnostic sanitizer mode that turns of optimizations and continues after the error does not fit with this idea and would need to remain separate, but it already does not play well with diagnostics. Martin
