https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #48 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (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 > as it makes copying objects byte-by-byte impossible. See > https://bugs.llvm.org/show_bug.cgi?id=44188 for a nice illustration. Note that the behavior of GCC with your testcase is unrelated to the LLVM issue and DR 260. And it is even reversed: here with GCC, the result of the comparison is *incorrect before* the (potentially invalid) copy of the pointer, and it is *correct after* the copy. It seems that the reason why the result incorrect before the copy is that GCC optimizes based on the fact that p and q points to distinct objects (or past to them), i.e. GCC considers that the pointers are necessarily different in such a case, without needing a further analysis. For repr and val2, I assume that GCC gives the correct result because it does not optimize: it just compares the representations of p and q, which are the same. > While at it, the testcase also demonstrates that the comparison `p == q` is > unstable. p == p would also be unstable: What could happen is that: 1. The implementation evaluates the first p. 2. The representation of p changes. 3. The implementation evaluates the second p. 4. Due to the different representations, the comparison returns false.
