<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="">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 class="">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>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.<br>
</div><div> </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 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 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 class="gmail_extra"><br></div><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>