On Thu, Mar 21, 2013 at 9:45 PM, John McCall <[email protected]> wrote:
> On Mar 21, 2013, at 6:19 PM, Reid Kleckner <[email protected]> wrote: > > + // FIXME: Emit a pair of {vbtable offset, field offset} when we know >> vbtable >> + // layout. >> + return GetBogusMemberPointer(QualType(MPT, 0)); >> >> I don't think this ever actually comes up here. If it did, you'd need a >> totally different interface anyway. >> > > Yeah, we do need a different interface. Testing this case hits assertions. > > > Oh, sorry, this case *will* come up, but only with a "null" vbtable offset. > The trick is that &A::foo always has the type of the actual member; the > type > "A" only matters for lookup. > > That is, if you have: > struct A { int x, y; }; > struct B : virtual A { int z; }; > then "&B::x" has type int A::*. (This is supposed to ignore using decls, > too.) > > Therefore, when you're forming a member pointer constant from a field, > the constant itself will always refer to a direct member of the base type > of the > member pointer type. That doesn't mean you can't have member pointer > constants that have vbase-offset fields — case in point, &B::z — but it > does > mean that those fields will always be the null value. > > That's assuming that MSVC follows the language rules about the type of a > member pointer constant, of course. > > + // For member data pointers, this is just a check against -1 or 0. >> + if (MPT->isMemberDataPointer()) { >> + assert(MemPtr->getType() == getPtrDiffTy()); >> + llvm::Constant *Val = getNullMemberDataPointer(MPT); >> + return Builder.CreateICmpNE(MemPtr, Val, "memptr.tobool"); >> + } >> >> You forgot the virtual inheritance case here. >> > > OK, fixed, that will issue an error instead of asserting now. > > > I haven't figured out exactly how to do this with a virtual base yet, and > Timur says that Clang currently has very little support for virtual > inheritance. I'd rather handle simple member data pointers that are just > offsets first, and then come back when we tackle virtual inheritance. > > > Okay. I mean, to me it makes sense to get easy cases out of the way while > you're thinking about them, but it's ultimately up to you. > > I'm pretty sure that the way that this works with virtual bases work is > that, if > the vbase offset field isn't null (and I'm not sure what that null value > is), then > it's an offset within the primary vbtbl for the class. So you ask the > record > layout for the offset of the vbtbl, load the vbtbl, add the offset, load a > size_t > out of that, and then just add that to the non-virtual offset. > Yes, this sounds right to me. I'm just not confident in my ability to encode it correctly in LLVM IR without spending more time writing tests that confirm compatibility with MSVC. > What this implies is that the act of converting member pointers between > classes that don't use the same primary vbtbl potentially involves a > case-by-case conversion between vbase offsets ("for offset 0, use offset 4; > for offset 4, use offset 12; for offset 8, use offset 0"), because > there's no > fixed relationship between the order of vbases in different vbtbls. > That sounds exciting.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
