https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343
--- Comment #3 from Gabriel Ravier <gabravier at gmail dot com> --- Well the code does not invoke undefined behavior here, it just so happens that `p == (x + 1)` because `y` happens to be laid out in memory after `x` (note: this isn't a guarantee, of course, but GCC can't prove this isn't the case as it's defined in another TU and it's quite easy to make this happen). The comparison doesn't imply the pointers have the same provenance, and the standard has a specific provision for this exact comparison: "If one pointer represents the address of a complete object, and another pointer represents the address one past the last element of a different complete object,72 the result of the comparison is unspecified." - [expr.eq] (https://eel.is/c++draft/expr.eq#3.1) Also, `y` isn't accessed through a pointer to `x`: I've already said the case where the function is incorrect is when `f` is called with `&y` as the first argument. If doing `p == (x + 1)` implied they derived from the same object, then that would imply after doing `&y == (x + 1)` doing `*&y` would invoke undefined behavior which is obviously ridiculous. Although there is a case to be made that this code is stupid and deserves a warning, though... I won't argue with that, this code is just something I wrote to test things after a 3 hour long conversation about DR 260 (<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm>) and a lot of standardese lawyering, so it's not intended to be real life code. I'd say, though, that the warning is quite inaccurate in the details of what it's saying, as `p` isn't actually equivalent to `(x + 1)` just because `p == (x + 1)`.
