<div dir="ltr"><div dir="ltr" class="gmail_msg">Ah - yep!<br class="gmail_msg"><br class="gmail_msg">Sent out <a href="https://reviews.llvm.org/D29233">https://reviews.llvm.org/D29233</a> - turned out  linkonce_odr/linkonce_odr is needed for the static local variables to meet the Itanium ABI (well, technically while linkonce_odr must be used in the use - there would be no harm in putting weak_odr in the definition, but no benefit either since the ABI doesn't guarantee it, so it cannot be depended on)<br><br>Richard & I also talked about the ramifications of this for Modular Codegen as well - we came to the conclusion that for now the same behavior can/should be used, but once modular codegen is implemented using a_e/weak could be experimented with and would be a valid implementation based on current ideas around where the ABI and contracts would be between objects in modular codegen scenarios. (essentially the idea was: modular objects will need to be ABI compatible with existing code (eg: maybe some of the code is built with Clang and moduels, some of the code is built with GCC) - but could provide extra ABI surface for objects generated by a compiler using those modules (eg: objects built by the compiler that built the modules used for modular codegen could depend on extra ABI surface, like weak_odr static locals)... that may've been a bit rambly, sorry - might be able to explain that better another time)<br><br>Thanks, Richard, for walking through all this with me.</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, Jan 26, 2017 at 5:43 PM Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="gmail_msg" target="_blank">mehdi.amini@apple.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Jan 26, 2017, at 2:51 PM, David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> In implementing modular codegen, specifically verifying the behavior for static local variables in inline functions in modular headers, I came across a piece of logic in Clang's linkage calculation that seems off.<br class="gmail_msg">
><br class="gmail_msg">
> To demonstrate a real-world example:<br class="gmail_msg">
><br class="gmail_msg">
> template<typename T><br class="gmail_msg">
> inline void f() { static int i; }<br class="gmail_msg">
> extern template void f<int>();<br class="gmail_msg">
> ...<br class="gmail_msg">
> template void f<int>();<br class="gmail_msg">
><br class="gmail_msg">
> In the TU with the extern template declaration, an available_externally definition of f<int> and f<int>::i are provided (when optimizations are enabled).<br class="gmail_msg">
><br class="gmail_msg">
> In the TU with the extern template definition, a weak_odr definition of f<int> is provided but a linkonce_odr definition of f<int>::i is provided.<br class="gmail_msg">
><br class="gmail_msg">
> This surprises me and doesn't seem correct. What if the TU with the weak_odr definition is optimized to the point of removing the f<int>::i definition - but the available_externally TU is not - it inlines f<int> but leaves a use of f<int>::i available?<br class="gmail_msg">
><br class="gmail_msg">
> What's the deal here - am I missing something that makes this safe/correct?<br class="gmail_msg">
<br class="gmail_msg">
Seems buggy to me, either it should be (decl / def ): available_externally / weak_odr or: linkonce_odr / linkonce_odr.<br class="gmail_msg">
<br class="gmail_msg">
Indeed based on your example, here are two source files and a header that fail to link on macOS when optimizations are enabled.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
—<br class="gmail_msg">
Mehdi<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>