<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 18, 2014 at 5:52 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Thu, Dec 18, 2014 at 5:46 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Thu, Dec 18, 2014 at 2:30 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Wednesday, December 17, 2014, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 17, 2014 at 3:52 PM, Rafael Espíndola <span dir="ltr"><<a>rafael.espindola@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Based on talking to David, we think the frontend should be responsible for<br>
> picking whether things are ODR or not, and then LLVM optimizations can<br>
> continue to be mostly ignorant of comdats. For example, the D5 destructor<br>
> comdat group functions should all be inlinable.<br>
<br>
</span>+1 :-)<br></blockquote><div><br></div><div>I think that makes a lot of sense. Does this imply that globals within a comdat would need to have some kind of weak linkage?</div></div></div></div></blockquote><div><br></div></div></div>The only non-weak linkage we allow in COMDATs is external.  The closest analog is weak_odr but it has subtly different semantics wrt duplicate symbol definitions.<br><div><br></div><div>I'll try to dig up a concrete example as soon as I can get to my laptop.</div></blockquote><div><br></div></div></div><div>I think Rafael's right here: external symbols in a comdat are meaningful (and presumably they mean that you can't have that symbol defined in any other object file you link in, so you either get your definition or no definition), and I can imagine (rare) cases when they might be what you want. (And if not, don't do that...)</div></div></div></div></blockquote><div><br></div></div></div><div>I think it means something different from what you are suggesting.  STB_WEAK is orthogonal to COMDAT-ness.  Clang when targeting MSVC uses COMDATs with external linkage to mean:</div><div>- This symbol is in some COMDAT group</div><div>- It is not weak, don't replace my symbol with some non-weak definition.</div><div>- This symbol cannot be discarded.</div><div><br></div><div>I don't think there is another combination of linkage and comdat-ness which gets the same effects.</div></div></div></div></blockquote><div><br></div><div>... in that case, all our interprocedural optimizations *do* need to know about comdats, and being in a comdat needs to make an external symbol effectively weak for optimization purposes (you can't propagate information out of it, because it might be replaced by a different definition). This violates Reid's desire that optimizations can be mostly ignorant of comdats.</div></div></div></div>