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.
