On 1/3/25 10:30 AM, Qing Zhao wrote:
On Jan 3, 2025, at 11:41, Richard Biener <richard.guent...@gmail.com> wrote:
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?
Path isolation pass is After bounds pass.
From my understanding, path isolation pass only insert TRAP on the
problematic path. The false positive warning on that path still there. Please
see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106762
Correct. But we have choices here. Forming the address doesn't actually
cause user visible UB, though it is UB in the IL.
Given it doesn't cause user visible UB, we could insert the trap
*before* the UB inducing statement. That would then make the statement
unreachable and it'd get removed avoiding the false positive diagnostic.
But path-isolation is too late in the gimple pipeline to really help us
here.
My work of adding -fdiagnostics-explain-harder also handled path isolation pass.
Should the loop unrolling pass need to be adjusted to avoid forming the invalid
pointers?
It it can reasonably be adjusted, it'd probably be good. It's an area
I'm not terribly familiar with.
jeff
