https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Harald van Dijk from comment #22)
> (In reply to Andrew Pinski from comment #21)
> > Invalid as mentioned a few times already but never actually closed until
> > now.
>
> I posted a strictly conforming program that with GCC does not behave as
> required by the standard. The issue is valid, even if the original test case
> is not.
If you are talking about the one in comment#12 then this is the same issue
as present in a few other "similar" bugs where GCC propagates conditional
equivalences (for example the linked PR65752):
v = &y;
p = v;
x = 2, y = 1;
if (p == &x + 1)
*p = 2;
is turned into
v = &y;
p = v;
x = 2, y = 1;
if (p == &x + 1)
*(&x + 1) = 2;
by GCC and the store is then no longer possibly aliasing y.
Conditional equivalences are a difficult thing to exploit for optimization
and there's some work in progress for the standard regarding to pointer
provenance which IIRC says that the comparison result of &y == &x + 1
returns an unspecified value. Not sure if that helps us but then the
only way our for GCC for this particular issue would be to never actually
propagate conditional equivalences.
Sth that might be worth investigating, but within the current structure of
the optimization passes that apply this transform it's impossible to decide
whether a value resulted from conditional equivalences or not... I'm also
not sure to what extent simplification results using a conditional predicate
like p == &x + 1 are affected as well.
IMHO it's a defect in the language if
p = &y;
if (p == &x + 1)
*p = 2;
is valid but
p = &y;
if (p == &x + 1)
*(&x + 1) = 2;
is invoking undefined behavior. Or at least a very uncomfortable situation
for a compiler writer. IMHO the pointer provenance work making the
comparison having unspecified result doesn't really help since that doesn't
make it invoke undefined behavior.
