[LLVMbugs] [Bug 22992] New: vtable linkage in key function TU differs between clang and gcc

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22992
           Summary: vtable linkage in key function TU differs between
                    clang and gcc
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: yaron.keren at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using gcc version 4.9.1 and clang trunk under Windows 7, the following C++
program creates COMDAT linkage for vtable and typeinfo in gcc but not in clang.

class C {
public:
  virtual void f();
};
void C::f() {}


>g++ -c v.cpp & dumpbin /headers v.o | grep COMDAT
         COMDAT; sym= __ZTV1C
         COMDAT; sym= __ZTI1C
         COMDAT; sym= __ZTS1C

>clang++ -target i686-pc-windows-gnu -c v.cpp & dumpbin /headers v.o | grep COMDAT


The difference is probably not related to Windows but the result of
CodeGenModule::getVTableLinkage returning ExternalLinkage for class C. This is
OK as the vtable will not be emitted in other TUs at least with clang. 

However, I am not sure if mixed compiling with clang and gcc-compiled objects
would not bomb in some situations.
There may be a reason why gcc produces weak vtables.

If it makes sense matching gcc behaviour, a patch would be to return
WeakODRLinkage instead of ExternalLinkage.

-- 
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/20150323/e261d56f/attachment.html>