[PATCH] [ms-cxxabi] Correctly compute the size of member pointers

João Matos ripzonetriton at gmail.com
Thu Mar 21 18:17:23 PDT 2013

On Thu, Mar 21, 2013 at 11:22 PM, Will Wilson <will at indefiant.com> wrote:

> Oddly enough I've been working on this exact area myself over the last few
> days. I could be overlooking something but it appears to be missing support
> for the X64 ABI (ie. amd64-pc-win32) which would be a shame not to
> support. I've previously spent some time analyzing it and came up with the
> following member function pointer sizes:

I agree, X64 ABI support would be nice.

The inheritance keywords should be definitive for the rest of the TU. MSVC
> will issue an error should the class definition not match the assigned
> inheritance keyword - this is a useful sanity check and probably worth
> implementing. The error in question is C2286 and is outlined here:
> http://msdn.microsoft.com/en-gb/library/9z8tbhb2.aspx

I already tried to add a warning for this, see r163078, but that got
reverted at the time. We should definitely add a warning for this.

In addition, MSVC has a nasty corner case. If a member function pointer
> is instantiated based on an (as yet) undefined class the class is assigned
> the unknown inheritance for the rest of the translation unit - even if the
> class is defined later in the TU. I've been wondering how best to model
> this persistant state and the only approach I could come up with was to
> assign a (currently unimplemented) UnknownInheritanceAttr during sema - but
> it's not pretty.

Interesting, that sounds indeed a bit tricky to implement.

> Lastly, I haven't had a chance to revisit it, but MSVC seems to do weird
> things with member function pointer alignment. I know this isn't specific
> to this patch but I thought I'd mention it. Hopefully I'll get the chance
> to research it soon and get to the bottom of the implementation.

 File a bug about this when you know more details so we do not forget it.

João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130322/0555e3f4/attachment.html>

More information about the cfe-commits mailing list