On Thu, Sep 23, 2021 at 12:48 PM David Blaikie via cfe-users <cfe-users@lists.llvm.org> wrote: > > On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users > <cfe-users@lists.llvm.org> wrote: >> ... >> Over on llvm-dev I'm trying to persuade them that declaring something as >> __declspec(dllimport) should automatically exclude it from being >> inlined. And to be honest, I'd be quite surprised if that's not what >> Microsoft intended. > > I think if it's clearly demonstrated that that's Microsoft's implementation - > that no matter how hard you ask it to optimize and how simple the function > is, that it won't inline a dllexported function that's inline in a header > (both implicitly inline in a class definition, and probably check the case of > a standalone dllexported inline non-member function in a header) that I'd say > (though I have little sway/weight in this design decision) clang-cl should > implement the same behavior, because it is observable/can be relied upon as > you have (though also - dllexported variables should be defined somewhere, > generally) & an opt-in flag to what is the current behavior > (dllexport-inlining).
I think this is the old binary compatibility problem, like exceptions crossing module boundaries. I think part of the problem is, Microsoft does not publish a specification. For years Borland had to figure it out by reverse engineering what MS was doing. I guess the situation has not gotten any better. Jeff _______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
