<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
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.  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>