https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110091
--- Comment #9 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> So the way m_check_dangling_p works seems wrong from the get go.
>
> We can only push one clobber on the hashtable and we only pop from the
> hashtable if there was a direct store to that variable.
>
> So for an example we might have:
> ```
> a {v}= {CLOBBER(eos)};
> c = b ? &a : &d;
> *c = t;
> if (b)
> e = a;
> else
> e = d;
> ```
> We would get a warning here. even though this is very much well defined.
Why is this well defined? Isn't the address of `a` being taken after the
storage has been invalidated, or have I misunderstood your point? It does walk
through VUSEs to look for indirect uses (see check_pointer_uses for example)
AFAICT and then avoids warning if there's a clobber of that variable after the
use. It's a bit clumsy but it works I think. What am I missing?
> I am thinking we should only do the warning inside the same BB for GCC 16;
> and file a bug to improve how we handle this where we can have multiple
> layers for the variable and such.
> I have not checked the testcases for Wdangling-pointer though to see what is
> currently being tried to be tested.
The current tests do look for references escaping across BBs, e.g. something
like this:
```
ptr *p;
if (i)
{
int a;
p = &a;
...
}
use (p);
```
> Also I am curious why it is checking CLOBBER_STORAGE_END rather than all
> clobbers.
It's looking for use after invalidation, so isn't it only missing
CLOBBER_OBJECT_END in that context? It was added in gcc-14, so it's not
surprising that it's missing.
