> On Jan 4, 2025, at 12:58, Jeff Law <jeffreya...@gmail.com> wrote: > > > > 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.
Yes, that’s a good idea. However, in order to distinguish a user visible UB and a UB in the IL that is introduced purely by compiler, we might need some new marking in the IR? Qing > > 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
