[LLVMbugs] [Bug 18479] New: MS ABI: Delay member pointer inheritance model lock-in until a complete type is required

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Jan 14 13:38:16 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18479

            Bug ID: 18479
           Summary: MS ABI: Delay member pointer inheritance model lock-in
                    until a complete type is required
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rnk at google.com
                CC: david.majnemer at gmail.com, llvmbugs at cs.uiuc.edu
            Blocks: 12477
    Classification: Unclassified

Right now we lock in the inheritance model of a member pointer in the Microsoft
C++ ABI when we build the type.  This means we use the unspecified inheritance
model (3 ints) for this code:

struct A;
void f(int A::*mp);
struct A { };
int main() { f(0); }

MSVC uses the single inheritance non-polymorphic model (1 int, null is -1) for
this code because it waits until it sees "f(0)" to decide on the size.  We can
probably get much better compatibility if we wait until RequireCompleteType()
is called on the member pointer type to decide the inheritance model.

Rather than stapling new attributes to the class decl like we currently do, we
could add a mutable enum field to MemberPointerType to hold the inheritance
model.  The model is determined once and it stays the same for that type
throughout the rest of the TU, so we can sidestep the immutability of Type. 
The inheritance model should *not* be part of the MemberPointerType profile, we
only need the pointee type and the class type.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140114/38e21169/attachment.html>


More information about the llvm-bugs mailing list