[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

["harald at gigawatt dot nl" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502

--- Comment #27 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Richard Biener from comment #25)
> (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):

Right, there are a lot of ways this can come up.

> 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.

For C++ it's http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1652

> Not sure if that helps us

I don't think it does. Although the change would allow p == &x + 1 to evaluate
as false even though they have the same address, there is no sane way for GCC
to actually let it evaluate it as false when p comes from a volatile variable.

> but then the
> only way our for GCC for this particular issue would be to never actually
> propagate conditional equivalences.

Well, there are two incompatible optimisations. This one could be disabled or
restricted, or see below.

> 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.

A legitimate reading of C90 and C99 says the second is valid as well, but it's
not the reading the committee went with. Allowing this, as an extension to what
the standards allow, would be a way to keep the p -> &x + 1 transformation
working. It would naturally break some of the current optimisations that GCC
performs, but so would the alternative.

(In reply to Richard Biener from comment #26)
> Unfortunately it isn't visible _what_ change fixed this

The revision number is listed in Richard Smith's second comment. The changes
can be seen with

  svn diff -c 220343 https://llvm.org/svn/llvm-project/

That's also where I got the C++ issue number from.

> and thus if just
> some more massaging of the testcase is necessary to make the bug resurface
> or if LLVM found a clever way to attack the underlying issue (whatever
> underlying issue LLVM had - I'm only guessing it may be the same conditional
> propagation).

When they turn a comparison between a pointer to an object and a pointer to one
past an object into a non-constant expression, that's apparently enough for
them to force the comparison to be performed at run-time.