here we try to guess the value of a pointer -- LLVM says we cannot guess it and GCC suspects we canhttps://godbolt.org/g/SFLwz4
-
-
good point but of course neither compiler cares about the actual value...
-
Indeed. At first it seems reasonable that a ptr converted from int could only meaningfully point to fixed hw or an obj whose addr leaked...
-
However pigeonhole principle makes things get nasty.
-
yes an LLVM bug is filed about the case where you make a pointer (on a 32-bit machine) and try to guess it in a loop and it thinks you can't
-
If your guess involves any accesses, I think the bug is invalid; the compiler can infer UB from the access.
-
Does it still happen if &i == (int*)cur is changed to (uintptr_t)i == cur?
-
There may be an argument that using an invalid pointer as an operand to == invokes UB, but ops on uintptr_t are all 100% well-defined.
- 3 more replies
New conversation -
-
-
But properly aligning it does not change the behavior. I think DR260 which I reference in another tweet covers this.
-
for a pretty messed up version of "covers"
-
DR260 is basically entirely inconsistent bullshit.
End of conversation
New conversation -
-
-
So if *p and *q alias, they only partly overlap, and the behavior is automatically undefined.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Any type ... that the runtime implementors felt like supporting. Looking at you, SSE vectors.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.