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

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 8 May 2018, harald at gigawatt dot nl wrote:

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

OK, so that's a frontend only change (constexpr).

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

I'm quite sure they manage to "optimize"

int a, b;
bool foo()
{
  return &a == &b;
}

as well as

int a, b;
bool foo(int i)
{
  if (i == 1)
    return &a == &b + i;
  return true;
}

hmm, clang 3.8 does not.  It even fails to optimize &a == &b + 2
which would be a valid optimization (to false) as this bug is only
about one-past, not about arbitrary compares.

As said the real issue in GCC is the propagation of the
address constant triggered by the conditional equality.
In the other PR that re-surfaces even for integer comparisons.