<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 14, 2014 at 11:01 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> 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"><div class="">On Wed, May 14, 2014 at 10:12 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, May 14, 2014 at 8:58 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br>


</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>I'm a bit concerned with moving the DLLImport/DLLExport related linkage calculation into Sema out of CodeGen.  I have a feeling that this will trigger warn_static_local_in_extern_inline when a static local variable inside of a dllimport'd function.<br>



<br>
Considering that other things like VTables and RTTI don't rely on the GVALinakge mechanism and will need the ability to "upgrade" some linkage to a DLLImport/DLLExport friendly linkage, I think I'd rather see a DLLImport/DLLExport handled via a function which takes an arbitrary llvm::GlobalVariable linkage and a Decl and figures out what the final linkage should be.<br>



<br></div>
This kind of upgrading is common inside of CodeGen, GetAddrOfGlobalTemporary is a notable example of this.]<br></blockquote><div><br></div><div>IMO the linkage at the AST level should reflect what the user wrote, and the user used dllexport plus inline, giving GVA_StrongODR.  This is useful information for other Clang-based tools.</div>

</div></div></div></blockquote><div><br></div></div><div>I'd agree with this if we modeled stuff like fapple-kext in there but we don't. There are things that we simply can't model like WeakAttr, we don't know if we will end up with WeakODR or WeakAny until we try to evaluate the initializer.</div>
</div></div></div></blockquote><div><br></div><div>I'll have to read up on WeakAttr tomorrow.</div><div> </div><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 class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>I think CodeGen will always have to munge GlobalValue linkages for entities that don't exist in the user's program, for example, vtables and global reference temporaries.</div></div>
</div>
</div></blockquote></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">This route will require us to duplicate handling of dllexport/dllimport in both AST and CodeGen, I'd rather it just see it live in CodeGen.</div>
</div></blockquote><div><br></div><div>True, we'll need both, but we already have this kind of code for entities that aren't part of the AST, like vtables.</div><div> </div><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">I'd be happier with this if we can move stuff like -fapple-kext into GVALinkage and we add more tests for static variables inside dllimport/dllexport'd functions.<br>
</div></div>
</blockquote></div><br></div><div class="gmail_extra">I view -fapple-kext as less of an AST-level, "what the user wrote" thing and more of a codegen option that hacks the ABI to maintain backwards compatibility with one of the Ancient Ones.</div>
</div>