[PATCH] D39347: Fix __has_unique_object_representations based on rsmith's input

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 28 09:24:08 PST 2017


erichkeane added inline comments.


================
Comment at: lib/AST/ASTContext.cpp:2238-2240
+  // All other pointers are unique.
+  if (Ty->isPointerType() || Ty->isMemberPointerType())
+    return true;
----------------
rsmith wrote:
> erichkeane wrote:
> > rsmith wrote:
> > > This is not correct: member pointer representations can have padding bits. In the MS ABI, a pointer to member function is a pointer followed by 0-3 ints, and if there's an odd number of ints, I expect there'll be 4 bytes of padding at the end of the representation on 64-bit targets.
> > > 
> > > I think you'll need to either add a `clang::CXXABI` entry point for determining whether a `MemberPointerType` has padding, or perhaps extend the existing `getMemberPointerWidthAndAlign` to also provide this information.
> > Based on looking through the two, I think I can just do this as Width%Align == 0, right?  I've got an incoming patch that does that, so hopefully that is sufficient.
> I don't think that will work; the MS implementation *sometimes* rounds the size up to the alignment. (... which sounds pretty dodgy to me; shouldn't the returned size always be a multiple of the returned alignment?)
Ah, right... I missed this part of the MicrosoftCXXABI:
  if (Target.getTriple().isArch64Bit())
    Width = llvm::alignTo(Width, Align);

So likely I can just do the same math as I implemented here, except before the width is reset in the alignTo here.

Thanks for getting back so quickly!  I'll get back on this once I get a patch for the array align error.


https://reviews.llvm.org/D39347





More information about the cfe-commits mailing list