> 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


Reply via email to