On 2/20/25 7:17 AM, Richard Biener wrote:
I hesitate to even bring it up (but we need to). Do we want to consider the
state/future of these warnings for gcc-16? Is this stuff salvageable? I
think there's utility in these warnings, but they're clearly a pain point
across multiple contexts.
What I'd like to see is less diagnostics emitted from random passes
but instead, like we did with the array-bounds pass, do it separately.
And then have those passes not be randomly spread but in one or two
places.
I think that's fair. The two that come to mind in terms of too tightly
integrated into an optimization pass are sprintf and all the stuff in
the strlen pass.
I think of the two the strlen bits are the most "interesting". My
recollection was the whole point was to get access to nuggets of
information in the strlen pass that would help drive down the false
positives.
At least conceptually if we found a way to expose the data in the IL or
turn the analysis into a reusable module to be used by the diagnostics
and the strlen optimizations independently that would take us in the
right direction much like we did with pulling the array bounds warnings
out of VRP.
As for where they fit in the pipeline. I'm torn as I tend to believe
that things are where they are for a reason. We need to be willing to
tolerate more false positives (and I am) to bring some cleanliness to
this problem.
I think the other thing we need to look at are various (sometimes
dubious) heuristics that possibly made sense at the time, but with the
knowledge we've gained we probably want to revisit.
But in general as you say the "advancd IL diagnostics" face the
same issue as static analyzers - we usually lack knowledge of all
pre-conditions to avoid false positives and there's no nice way
to annotate source with those in a way not affecting code generation
(because we warn off the IL, so those need to be in the IL itself).
The analyzer should have the very same issue here. There's Qings
patch to improve the diagnostic to help users write missing
pre-conditions, so that's a thing to look at.
I think you've hit one of the other key pain points. We've often found
it quite hard at times to turn off the diagnostics properly, either with
a pragma or careful use of __builtin_unreachable. That's really hard on
the end users.
Jeff
