forked from OSchip/llvm-project
cef66e5281
Under Windows Itanium, we need to export virtual and non-virtual thunks if the functions being thunked are exported. These thunks would previously inherit their dllexport attribute from the declaration, but r298330 changed declarations to not have dllexport attributes. We therefore need to add the dllexport attribute to the definition ourselves now. This is consistent with MinGW GCC's behavior. This redoes r306770 but limits the logic to Itanium. MicrosoftCXXABI's setThunkLinkage ensures that thunks aren't exported under that ABI, so I'm handling this in ItaniumCXXABI's setThunkLinkage for symmetry. We need to export these thunks because they can be referenced outside the library they're defined in. For example, if a child class without a key function inherits from a parent class with a key function, the parent's thunks will only be defined in the library with the key function, but the construction vtable for the parent in the child might be emitted outside the library (since the child doesn't have a key function), and it needs to reference the parent's thunks. We don't need to mark these thunks as imported since any references to them will occur in data, so the compiler can't generate the IAT load sequence anyway. Instead, we rely on the linker generating import thunks for the thunks. Differential Revision: https://reviews.llvm.org/D34972 llvm-svn: 308899 |
||
---|---|---|
.. | ||
INPUTS | ||
bindings | ||
cmake | ||
docs | ||
examples | ||
include | ||
lib | ||
runtime | ||
test | ||
tools | ||
unittests | ||
utils | ||
www | ||
.arcconfig | ||
.clang-format | ||
.clang-tidy | ||
.gitignore | ||
CMakeLists.txt | ||
CODE_OWNERS.TXT | ||
INSTALL.txt | ||
LICENSE.TXT | ||
ModuleInfo.txt | ||
NOTES.txt | ||
README.txt |
README.txt
//===----------------------------------------------------------------------===// // C Language Family Front-end //===----------------------------------------------------------------------===// Welcome to Clang. This is a compiler front-end for the C family of languages (C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM compiler infrastructure project. Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source-level tools. One example of this is the Clang Static Analyzer. If you're interested in more (including how to build Clang) it is best to read the relevant web sites. Here are some pointers: Information on Clang: http://clang.llvm.org/ Building and using Clang: http://clang.llvm.org/get_started.html Clang Static Analyzer: http://clang-analyzer.llvm.org/ Information on the LLVM project: http://llvm.org/ If you have questions or comments about Clang, a great place to discuss them is on the Clang development mailing list: http://lists.llvm.org/mailman/listinfo/cfe-dev If you find a bug in Clang, please file it in the LLVM bug tracker: http://llvm.org/bugs/