https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343
--- Comment #4 from Lénárd Szolnoki <leni536 at gmail dot com> --- A complete program example: f.h: ``` #pragma once extern int x[1]; extern int y; int f(int* p, int* q); ``` f.cpp: ``` #include "f.h" int f(int* p, int* q) { *q = y; if (p == (x + 1)) { *p = 2; return y; } return 0; } ``` x_y.cpp: ``` #include "f.h" int y; int x[1]; ``` main.cpp: ``` #include "f.h" int main() { y=1; int i; return f(&y, &i); } ``` Compile with `g++ -o main main.cpp f.cpp x_y.cpp`. https://godbolt.org/z/G4KTKc7hE The well-formed program above has two possible evaluations, due to the unspecified comparison. In one evaluation `main` returns 0, in the other it returns 2. Compiled with g++ the program returns 1. Within the single invocation of `f` `p` is pointer to an object, namely `y`. Even after the unspecified comparison evaluates to true, `p` remains a pointer to `y`. Therefore dereferencing `p` is still valid in that branch. I don't think that it is a duplicate of bug 61502. The program does not rely on the object representation of the pointer objects, their printed value or their value converted to uintptr_t. The only thing that is questionable is the comparison with pointer past the end of an object, which is merely unspecified.