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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #48 from Vincent Lefèvre --- (In reply to Alexander Cherepanov from comment #35) > DR 260 allows one to argue that representation of these pointers could > change right between the checks but IMHO this part of DR 260 is just wrong >

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #47 from Eric Gallager --- (In reply to Andrew Pinski from comment #46) > Note this came up on twitter the other day: > https://twitter.com/rep_stosq_void/status/1461635511009828864 Wayback Machine link, since the original has been

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #46 from Andrew Pinski --- Note this came up on twitter the other day: https://twitter.com/rep_stosq_void/status/1461635511009828864

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #44 from rguenther at suse dot de --- On Mon, 20 Jan 2020, ch3root at openwall dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 > > --- Comment #43 from Alexander Cherepanov --- > The following example

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #43 from Alexander Cherepanov --- The following example demonstrates that the instability taints the surrounding code even if it's in dead code itself. In particular, this shows that even making comparisons like ` + 1 == ` undefined

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #42 from Alexander Cherepanov --- I've recently stumbled upon a straightforward description (from Hal Finkel, in https://bugs.llvm.org/show_bug.cgi?id=34548#c77) for the thing that bothered me in the second part of comment 17.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #41 from Alexander Cherepanov --- (In reply to Richard Biener from comment #38) > (In reply to Alexander Cherepanov from comment #37) > > On 30/12/2019 10.51, rguenther at suse dot de wrote: > > >> Obviously, it could be used to fold

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #40 from Alexander Cherepanov --- Example with a flexible array member: -- #include #include __attribute__((noipa)) // imagine it in a separate TU static void

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #39 from Alexander Cherepanov --- For diversity, a couple of examples with zero sized objects. Even though they don't have pointer arithmetic at all they could be classified as being about past-the-end pointers:-) Please let me know

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #38 from Richard Biener --- (In reply to Alexander Cherepanov from comment #37) > On 30/12/2019 10.51, rguenther at suse dot de wrote: > >> Obviously, it could be used to fold `a + i == b` to `0` if `a` and `b` > >> are two different

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #37 from Alexander Cherepanov --- On 30/12/2019 10.51, rguenther at suse dot de wrote: >> Obviously, it could be used to fold `a + i == b` to `0` if `a` and `b` >> are two different known arrays and `i` is unknown > > That's indeed

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #36 from rguenther at suse dot de --- On December 29, 2019 6:42:55 PM GMT+01:00, ch3root at openwall dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 > >--- Comment #35 from Alexander Cherepanov >--- >What remains

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #35 from Alexander Cherepanov --- What remains in this pr is the original problem. 1. The best way to demonstrate that there is indeed a bug here is probably to compare representation of pointers directly:

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #34 from Alexander Cherepanov --- It seems to me that problems with the optimization `if (p == q) use p` -> `if (p == q) use q` (comment 4 etc.) are not specific to past-the-end pointers. So I filed a separated bug for it with

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org ---

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Andrew Pinski changed: What|Removed |Added CC||SztfG at yandex dot ru --- Comment #31

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Richard Biener changed: What|Removed |Added Blocks||85800 --- Comment #30 from Richard

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #29 from Peter Sewell --- On 8 May 2018 at 08:22, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 > > --- Comment #25 from Richard Biener --- > (In reply to Harald

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #28 from 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 --- > (In reply to Richard Biener from

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #27 from Harald van Dijk --- (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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #26 from Richard Biener --- (In reply to James Y Knight from comment #24) > FWIW, clang did consider this a bug and fixed it in > https://bugs.llvm.org/show_bug.cgi?id=21327. Unfortunately it isn't visible _what_ change fixed this

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #25 from Richard Biener --- (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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #24

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Richard Biener changed: What|Removed |Added Status|RESOLVED|SUSPENDED Last reconfirmed|

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #22 from Harald van Dijk --- (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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #20 from Andrew Pinski --- (In reply to Alexander Cherepanov from comment #19) > (In reply to jos...@codesourcery.com from comment #3) > > Except within a larger object, I'm not aware of any reason the cases of > > two objects

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #19 from Alexander Cherepanov --- (In reply to jos...@codesourcery.com from comment #3) > Except within a larger object, I'm not aware of any reason the cases of > two objects following or not following each other in memory must be

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #18 from Alexander Cherepanov --- A bit simplified variant: #include int main() { int x, y = 1; int *volatile v; int *p; v = p = v; if (p == + 1) { *p = 2; printf("y = %d\n", y); } } 077t.alias

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Alexander Cherepanov changed: What|Removed |Added CC||ch3root at openwall dot com ---

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||gcc at

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Sun, 26 Oct 2014, Keith.S.Thompson at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #14 from Keith Thompson

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #14 from Keith Thompson Keith.S.Thompson at gmail dot com --- The C standard requires that, if y happens to immediately follow x in the address space, then a pointer just past the end of x shall compare equal to a pointer to the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Harald van Dijk from comment #4) That's an interesting argument. You may well be right that the original code, strictly speaking, does not prove that GCC has a bug,

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #12 from Harald van Dijk harald at gigawatt dot nl --- (In reply to Richard Biener from comment #11) I can't reproduce your findings with any of the specified GCC version nor with any other I tried (I tried on x86_64-linux and

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Wed, 22 Oct 2014, Keith.S.Thompson at gmail dot com wrote: Do you believe that the authors of the standard meant it the way you do? The authors of the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC|

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #6 from Keith Thompson Keith.S.Thompson at gmail dot com --- In the test case for Bug 63611 (marked as a duplicate of this one) we have: element x[1]; element y[1]; element *const x0 = x; element *const x1 = x0 + 1;

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 21 Oct 2014, Keith.S.Thompson at gmail dot com wrote: their last-stored values. Furthermore, even if relocating objects so they're no long adjacent

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #8 from Keith Thompson Keith.S.Thompson at gmail dot com --- I'm not (deliberately) considering anything other than the requirements of the C standard. The standard talks about an array object immediately following another array

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 21 Oct 2014, Keith.S.Thompson at gmail dot com wrote: Are you saying it's possible that y immediately follows x in the address space when that line

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #10 from Keith Thompson Keith.S.Thompson at gmail dot com --- I strongly disagree with your interpretation. Do you believe that the authors of the standard meant it the way you do? I suggest that the footnote: Two objects may be