On Fri, Jan 10, 2025 at 9:43 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > 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.
Yes, but as said it's niter analysis that needs the improvement. Both possible for detecting the strlen() and for handling UB in address-takens to bound the number of iterations. > 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. Sure - I do think catching UB in path isolation is a good thing. But then path isolation is run quite early for some of our late UB diagnostic code, thus we might miss diagnostics then unless we can force-keep the UB triggering stmt (as we do for NULL pointer derefs). > > > > 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. Yeah. > 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. Yes, having a diagnostic defered and keyed on survival of __builtin_warning is a good thing. The diagnostic machinery might be good enough to stash a fully formatted multi-line diagnostic aside and replay it later - David probably knows best. > 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. I don't think we want to change it too much at this point - esp. using more UB for niter analysis. What might be OK is to improve loop_niter_by_eval, I'll have a short look to see what this would mean (it's very restrictive at the moment). Richard. > jeff >
