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.
