> Am 03.01.2025 um 16:22 schrieb Jeff Law <jeffreya...@gmail.com>:
>
> So this is an implementation of an idea I had a few years back and
> prototyped last spring to fix pr92539.
>
> pr92539 is a false positive Warray-bounds warning triggered by loop
> unrolling. The warning is in code that will never execute, but none of the
> optimizers clean things up well enough or early enough in the pipeline to
> avoid the warning.
>
> To optimize away the code we can take advantage of the fact that we're
> comparing a value to a bogus pointer. So for example an EQ comparison
> against &"aa" + 3 is always false and a NE comparison against that would
> always be true.
Forming the pointer invokes UB, the comparison is neither false nor true. I’d
say this is a classical case for path isolation on the pointer forming, not
only discarding either the true or false path of the compare.
The path isolation pass is probably too late in this case?
> I've implemented this in vr-values. It's not my preferred location, but we
> need to handle this scenario before the array-bounds warnings which are
> currently placed immediately after vrp1. So vr-values it was...
>
> This could perhaps also be done in match.pd; there's a reasonable chance it's
> implementable there and would trigger early enough in the pipeline to avoid
> the false positive. I can certainly explore that if folks think that's a
> better solution to this long standing issue.
>
> Bootstrapped and regression tested on x86_64 and run through the crosses in
> my tester.
>
> Anyway, thoughts?
>
> Jeff
>
> <P>
