[PATCH] D124571: Avoid strict aliasing violation on type punning inside llvm::PointerIntPair

Breno Rodrigues Guimaraes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 3 21:49:22 PDT 2022


brenoguim added inline comments.


================
Comment at: llvm/include/llvm/ADT/PointerIntPair.h:46
+
+  Ptr *getPointerAddress() { return reinterpret_cast<Ptr *>(Data); }
+  const Ptr *getPointerAddress() const { return reinterpret_cast<Ptr *>(Data); }
----------------
akyrtzi wrote:
> I'm wondering if the standard "blesses" this use of `reinterpret_cast` or whether it's some kind of UB..
I can't find an explicit blessing in the standard, but I suppose this is fine by making a parallel with allocators:

Some allocators work by creating arrays of bytes and doing placement new on those bytes to form an object. That's perfectly valid.
The allocator can at anytime retrieve a `T*` from the `byte*` it has, as long as it had allocated the object there.

That's pretty much what we do here. We create a buffer and pretend to have a `Ptr` there.
Although, there we might be missing two things to be truly correct:
- May need to call placement new. It's a noop being a trivial type, but still...
- May need to call std::launder to indicate an object of type `Ptr` is supposed to be there. But that's C++17

So in the constructor I could do `new (Data) Ptr` just to be extra clear to the compiler that the buffer holds a `Ptr`.

But It's very hard to interpret the standard, so my analysis could be way off.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124571/new/

https://reviews.llvm.org/D124571



More information about the llvm-commits mailing list