[llvm-bugs] [Bug 36921] New: [MSVC compatibility] Compiled executable crashes when using multiple virtual bases

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36921

            Bug ID: 36921
           Summary: [MSVC compatibility] Compiled executable crashes when
                    using multiple virtual bases
           Product: clang
           Version: 6.0
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: budai at tresorit.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20135
  --> https://bugs.llvm.org/attachment.cgi?id=20135&action=edit
Minimal C++ source that produces the bug

Clang for Windows with MSVC 2017.

Consider the following source code:

    struct A {
        virtual ~A() {}
    };
    struct B {
        virtual ~B() {}
    };
    struct C : virtual B {};
    struct D : virtual A, C {};
    int main()
    {
        delete new D;
    }

Running:

    $ clang source.cpp

from x64 Native Command Prompt for VS 2017 results in an executable that
crashes upon startup.

We've examined the generated output and found that, when the compiler generates
code for the destructors of `D` and its virtual base classes, the compiler
miscalculates the base offset of the `this` pointer for the virtual base class
`A`, it sets 16 instead of 8.

Here is the constructor of D:

"??0D@@QEAA at XZ":                        # @"\01??0D@@QEAA at XZ"
.LBB1_2:
    xor edx, edx
    mov rax, qword ptr [rsp + 56] # 8-byte Reload
    mov rcx, rax
    call    "??0C@@QEAA at XZ"
    lea rcx, [rip + "??_7D@@6BC@@@"]
    lea r8, [rip + "??_7D@@6BA@@@"]
    mov r9, qword ptr [rsp + 56] # 8-byte Reload
    mov r10, qword ptr [r9]
    movsxd  r10, dword ptr [r10 + 8]
    add r10, 0
    mov qword ptr [r9 + r10], r8      # sets A's vtable to ??_7D@@6BA@@@
    mov r8, qword ptr [r9]
    movsxd  r8, dword ptr [r8 + 4]
    add r8, 0
    mov qword ptr [r9 + r8], rcx
    mov rcx, qword ptr [rsp + 80]
    mov qword ptr [rsp + 32], rax # 8-byte Spill
                                      # sets B/C's vtable to ??_7D@@6BC@@@
    mov rax, rcx
    add rsp, 88
    ret
Vtable:
    .globl  "??_7D@@6BA@@@"
"??_7D@@6BA@@@" = .L__unnamed_1+8
.L__unnamed_1:
    .quad   "??_R4D@@6BA@@@"
    .quad   "??_GD@@UEAAPEAXI at Z"

Generated destructor for A:
"??_GD@@UEAAPEAXI at Z":                   # @"\01??_GD@@UEAAPEAXI at Z"
.seh_proc "??_GD@@UEAAPEAXI at Z"
# %bb.0:
    sub rsp, 72
    .seh_stackalloc 72
    .seh_endprologue
    mov dword ptr [rsp + 60], edx
    mov qword ptr [rsp + 48], rcx
    mov rcx, qword ptr [rsp + 48]
    add rcx, -16                     # note offset is 16 here
    mov rax, rcx
    mov qword ptr [rsp + 64], rax
    mov edx, dword ptr [rsp + 60]
    mov qword ptr [rsp + 40], rcx # 8-byte Spill
    mov dword ptr [rsp + 36], edx # 4-byte Spill
    call    "??_DD@@QEAAXXZ"
    mov edx, dword ptr [rsp + 36] # 4-byte Reload
    cmp edx, 0
    je  .LBB5_2

But in the dumped record layout, A is at offset 8:

*** Dumping AST Record Layout
         0 | struct A
         0 |   (A vftable pointer)
           | [sizeof=8, align=8,
           |  nvsize=8, nvalign=8]
*** Dumping AST Record Layout
         0 | struct B
         0 |   (B vftable pointer)
           | [sizeof=8, align=8,
           |  nvsize=8, nvalign=8]
*** Dumping AST Record Layout
         0 | struct C
         0 |   (C vbtable pointer)
         8 |   struct B (virtual base)
         8 |     (B vftable pointer)
           | [sizeof=16, align=8,
           |  nvsize=8, nvalign=8]
*** Dumping AST Record Layout
         0 | struct D
         0 |   struct C (base)
         0 |     (C vbtable pointer)
         8 |   struct A (virtual base)
         8 |     (A vftable pointer)
        16 |   struct B (virtual base)
        16 |     (B vftable pointer)
           | [sizeof=24, align=8,
           |  nvsize=8, nvalign=8]

-- 
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/20180327/47f2b606/attachment.html>