On Wed, May 14, 2014 at 11:01 PM, David Majnemer <[email protected]>wrote:
> On Wed, May 14, 2014 at 10:12 PM, Reid Kleckner <[email protected]> wrote: > >> On Wed, May 14, 2014 at 8:58 PM, David Majnemer <[email protected] >> > wrote: >> >>> 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. >>> >>> 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. >>> >>> This kind of upgrading is common inside of CodeGen, >>> GetAddrOfGlobalTemporary is a notable example of this.] >>> >> >> 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'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. > I'll have to read up on WeakAttr tomorrow. > 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. >> > > 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. > True, we'll need both, but we already have this kind of code for entities that aren't part of the AST, like vtables. > 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. > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
