[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #8 from Tim Ruehsen --- Here is a good blog post about pointer overflow: https://blog.regehr.org/archives/1395
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #7 from Tim Ruehsen --- Thanks for the explanations :-)
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #6 from Richard Biener --- You can use -fwrapv-pointer to make pointer-wrapping defined. In C you are only allowed to use relational compares on pointers to the same object. On x86-linux there is no valid object at address zero thus an object cannot start at 0xf3e0080c and be of your size, wrapping around (and including) zero. The optimization that is performed is rewriting a > a + n as 0 > n which is quite useful in other contexts.
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #5 from Andrew Pinski --- I mean comparisons which are not equals or not equals outside of array bounds is undefined.
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #4 from Andrew Pinski --- Also this was an a broken ABI mistake a long time ago. Also comparing for non equality outside an array bounds (besides one past the end) is also undefined behavior. Undefined behavior does NOT need to be consistent behavior even at runtime.
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #3 from Andrew Pinski --- Sorry i mean ptrdiff_t .
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 --- Comment #2 from Tim Ruehsen --- Is ssize_t C99 ? Could you point to the specs so that any reader can verify that ? And by UB you mean, gcc sometimes gives 0 and sometimes 1 ? Even if it's UB, the behavior should be consistent. Since this is a real world issue - how can I reliably detect if 'p + n' would overflow or not if the checks sometimes work and sometimes not.
[Bug middle-end/91946] wrong result comparing pointer with pointer+offset with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- 32bit ABIs have a ssize_t of 32bits which means you can only describe 31bits really. This makes wrapping around of the pointer is undefined.
