On 1/10/25 1:00 AM, Richard Biener wrote:
It's a problem we're never going to fully solve. Some of the
testcases show missed optimizations which we can work on. Some show
we diagnose IL we later are able to optimize away, some simply show
that users are not always happy with how we decide on suppressing a
diagnostic.
For the case at hand we should be able to optimize it fully.
Do you think it's reasonable to approach in unrolling? I'm just not
familiar enough with that code to even hazard a guess.
And any thoughts on putting this into path isolation? It wouldn't help
with the false positive from -Warray-bounds, but it does fit into what
that pass is generally trying to do and would at least make the final
code tighter. That would also give us a chance to clean up if user code
made similar goofs while still giving a suitable diagnostic.
But optimizing based on UB is always going to be to interact with
diagnosing UB, so we have to be careful. Our "late" diagnostics are
most problematic here and I'd argue moving those earlier is the
first thing we should try.
There's philosophical disagreements on where these warnings belong. As
you go earlier you get more false positives, but fewer false negatives
and the opposite as you push the analysis later in the pipeline.
That's what drove my high level support of the __builtin_warning idea as
well as earlier ideas around two-stage detection with a flag indicating
if the user wanted the early diagnostic or the later one.
Coming back to the bug. Unless there's a really simple way to catch in
the unroller, this one probably won't make gcc-15.
jeff
