https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121143
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |false-positive,
| |missed-optimization
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> My bet is that before cunroll we didn't know that __n_206 is 9 and during
> cunroll we completely unroll the loop that computes it and when processing
> the next loop we use ranger to ask about __n_206 value, get that it is 9 and
> assume the loop has exactly 9 iterations. Nothing has removed the loop as
> dead though because of __n_206 it will __throw_bad_alloc and so the warning
> is correct, but on a dead loop.
> No idea how to prevent that though.
This might be a case where the idea of delaying warning emission to later
and only do it if the associated stmt/location isn't elided would work.
I suppose the dead loop is elided later?
But yeah, it's impossible to get rid of all of these kind of false positives.
