<div dir="ltr">I don't think we'd want to keep marking C++ entities as weak/linkonce/etc. in the MSVC ABI if we are splitting the COMDATness out.  I guess we still sorta need it to talk about the discardability of a symbol...</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 4:39 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is the new version of the patch now that the llvm syntax change is in.<br>
<br>
The llvm IR until recently had no support for comdats. This was a<br>
problem when targeting C++ on ELF/COFF as just using weak linkage<br>
would cause quite a bit of dead bits to remain on the executable<br>
(unless -ffunction-sections, -fdata-sections and --gc-sections were<br>
used).<br>
<br>
To fix the problem, llvm's codegen will just assume that any weak or<br>
linkonce that is not in an explicit comdat should be output in one<br>
with the same name as the global.<br>
<br>
This unfortunately breaks cases like pr19848 where a weak symbol is<br>
not expected to be part of any comdat.<br>
<br>
Now that we have explicit comdats in the IR, we can finally get both<br>
cases right.<br>
<br>
This first patch just makes clang give explicit comdats to<br>
GlobalValues where it is allowed to.<br>
<br>
A followup patch to llvm will then stop implicitly producing comdats.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>