Dimitry Andric via llvm-dev
2021-Sep-22 12:33 UTC
[llvm-dev] Disabling inline compilation (Clang with VS2019)
On 22 Sep 2021, at 14:22, John Emmas via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi there - I first asked this question over on clang-users but I got advised to ask it here (sorry about the length...) > > I'm a VS2019 user and I've been trying to switch it here to use Clang as the compiler, rather than MSVC. But I seem to have hit a common problem. Consider the following code:- > > #if defined (BUILDING_DLL) > #define DLL_API __declspec(dllexport) > #else > #define DLL_API __declspec(dllimport) > #endif > > namespace Gtkmm2ext { > > class DLL_API Keyboard > { > public: > Keyboard (); > ~Keyboard (); > > static Keyboard& get_keyboard() { return *_the_keyboard; } > > protected: > static Keyboard* _the_keyboard; > }; > > } /* namespace */ > > The above code is from a DLL which gets used by an exe. The DLL compiles and links just fine and the exe compiles. But when I try to link the exe, Clang's linker complains that it can't find '_the_keyboard'As far as I understand it, if you specify __declspec(dllexport) for a whole class, then *all* members, including statics, get explicitly exported in the DLL image. I.e. it is as if you had manually specified __declspec(dllexport) to each and every member. I don't know if there is any way to override that for just a single class member, for example as with gcc you could add a __attribute__((visibility("hidden"))) to one of them. So maybe you can selectively add DLL_API to those class members that you need exported, as described here: https://docs.microsoft.com/en-us/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=msvc-160#_pluslang_using_dllimport_and_dllexport_in_c2b2bselectivememberimportexport -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210922/1798697e/attachment.sig>
John Emmas via llvm-dev
2021-Sep-22 12:50 UTC
[llvm-dev] Disabling inline compilation (Clang with VS2019)
On 22/09/2021 13:33, Dimitry Andric wrote:> . > As far as I understand it, if you specify __declspec(dllexport) for a whole class, then *all* members, including statics, get explicitly exported in the DLL image. > > I.e. it is as if you had manually specified __declspec(dllexport) to each and every member. >Thanks Dimitry - but why would that cause a problem? ''_the_keyboard" should never be needed by the exe - so why would the linker complain that it can't find something which it doesn't need anyway? John
Eric Astor via llvm-dev
2021-Sep-22 12:53 UTC
[llvm-dev] Disabling inline compilation (Clang with VS2019)
I've transferred John's example into Compiler Explorer, which will hopefully be a useful demonstration. Both clang and MSVC handle the dllexport case identically... but they do differ in the dllimport case: https://godbolt.org/z/vTrEevY8o Just as John suggested, disassembling the output shows that clang is inlining this function, even at -O1, where MSVC doesn't, even at /O3. I'd agree that this isn't a great match, though it *is* a point of ambiguity in the handling of __declspec(dllimport). One possible workaround: add a noinline marker on functions defined in headers that need to access protected members. ( https://godbolt.org/z/Pe67ovMnP) IMO, the best option would be to just adopt the policy that you don't define DLL_API functions in headers... which I would suggest is the best option anyway, since you don't want your importing code to have the definition. Either way, we should probably decide how we want clang to behave in this case. It's possible we should treat anything marked as __declspec(dllimport) as defined externally, and ignore any definition present in the source code? On Wed, Sep 22, 2021 at 8:33 AM Dimitry Andric via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 22 Sep 2021, at 14:22, John Emmas via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > > Hi there - I first asked this question over on clang-users but I got > advised to ask it here (sorry about the length...) > > > > I'm a VS2019 user and I've been trying to switch it here to use Clang as > the compiler, rather than MSVC. But I seem to have hit a common problem. > Consider the following code:- > > > > #if defined (BUILDING_DLL) > > #define DLL_API __declspec(dllexport) > > #else > > #define DLL_API __declspec(dllimport) > > #endif > > > > namespace Gtkmm2ext { > > > > class DLL_API Keyboard > > { > > public: > > Keyboard (); > > ~Keyboard (); > > > > static Keyboard& get_keyboard() { return *_the_keyboard; } > > > > protected: > > static Keyboard* _the_keyboard; > > }; > > > > } /* namespace */ > > > > The above code is from a DLL which gets used by an exe. The DLL > compiles and links just fine and the exe compiles. But when I try to link > the exe, Clang's linker complains that it can't find '_the_keyboard' > > As far as I understand it, if you specify __declspec(dllexport) for a > whole class, then *all* members, including statics, get explicitly exported > in the DLL image. > > I.e. it is as if you had manually specified __declspec(dllexport) to each > and every member. I don't know if there is any way to override that for > just a single class member, for example as with gcc you could add a > __attribute__((visibility("hidden"))) to one of them. > > So maybe you can selectively add DLL_API to those class members that you > need exported, as described here: > > https://docs.microsoft.com/en-us/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=msvc-160#_pluslang_using_dllimport_and_dllexport_in_c2b2bselectivememberimportexport > > -Dimitry > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210922/5238fe87/attachment.html>
John Emmas via llvm-dev
2021-Dec-03 16:21 UTC
[llvm-dev] [UPDATE] Disabling inline compilation (Clang with VS2019)
Just an update to a long gone thread.... Back in September I flagged up some problematic code which was building fine with MSVC but failing to link when built with Visual Studio and Clang. In the end, it turned out to be a typo at my end but along the way we discovered a difference in the way that MSVC and Clang will each treat functions declared using '__declspec(dllimport) ' Basically, Clang was sometimes trying to inline them when MSVC wasn't (I've added the relevant part of the discussion below...) The devs here said they'd be happy to make Clang's behaviour match MSVC but that it was traditionally hard to find out what Visual Studio's 'rules' are. So I posted a question on the VS developer forum - and 3 months later, Microsoft's own devs have finally replied:- https://developercommunity.visualstudio.com/t/__declspecdllimport-and-inline-abili/1537756#T-ND1602459 I know it's ancient history now but given that the situation's been clarified at last, I figured I might as well feed it back here. Basically, although the rules can change over time, currently (for dllimport functions) MSVC carries out 2 simple tests when deciding whether or not they can be candidates for inlining:- 1) the MSVC optimizer won't inline a candidate if that candidate calls some other function - and/or 2) the MSVC optimizer won't inline a candidate if that candidate accesses a global variable For class variables, a static member is treated as being a global variable. Like I said, I know it's all a long gone problem but I figured Microsoft's reply would be worth flagging up. Hope it all helps, John On 22/09/2021 13:53, Eric Astor wrote:> I've transferred John's example into Compiler Explorer, which will > hopefully be a useful demonstration. Both clang and MSVC handle the > dllexport case identically... but they do differ in the dllimport > case: https://godbolt.org/z/vTrEevY8o > > Just as John suggested, disassembling the output shows that clang is > inlining this function, even at -O1, where MSVC doesn't, even at /O3. > > I'd agree that this isn't a great match, though it *is* a point of > ambiguity in the handling of __declspec(dllimport). > > > On 22/09/2021 13:22, John Emmas wrote: >> Hi there - I first asked this question over on clang-users but I >> got advised to ask it here (sorry about the length...) >> >> I'm a VS2019 user and I've been trying to switch it here to use >> Clang as the compiler, rather than MSVC. But I seem to have hit a >> common problem. Consider the following code:- >> >> #if defined (BUILDING_DLL) >> #define DLL_API __declspec(dllexport) >> #else >> #define DLL_API __declspec(dllimport) >> #endif >> >> namespace Gtkmm2ext { >> >> class DLL_API Keyboard >> { >> public: >> Keyboard (); >> ~Keyboard (); >> >> static Keyboard& get_keyboard() { return *_the_keyboard; } >> >> protected: >> static Keyboard* _the_keyboard; >> }; >> >> } /* namespace */ >> >> The above code is from a DLL which gets used by an exe. The DLL >> compiles and links just fine and the exe compiles. But when I >> try to link the exe, Clang's linker complains that it can't find >> '_the_keyboard' >> >> But here's the thing... '_the_keyboard' is an internal variable >> that's private to the DLL. It should never need to get accessed >> by the exe. If I change 'get_keyboard()' to be just a >> declaration (and then implement it in a DLL source file) Clang is >> then happy - but unfortunately, this is one of several hundred >> similar linker errors. >> >> So I'm wondering if (maybe) the compiler implemented its call to >> 'get_keyboard()' as inline code, rather than importing it from >> the DLL? Maybe for very simple code like this, Clang is trying >> to be clever and implement stuff inline if it can? >> >> VS2019 can disable inline code via a compiler option called >> "/Ob0" - and typing "clang-cl /?" indicates that "/Ob0" is >> supported. But I still see the error, even if I specify "/Ob0" >> during compilation. >> >> So will "/Ob0" disable all inline compilation for Clang? Or does >> it only take effect where there's an actual 'inline' keyword? >> Hope that all makes sense... >> >> John >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211203/2ee31dab/attachment.html>