See:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40636/consoleFull#-39956214149ba4694-19c4-4d7e-bec5-911270d8a58c
```
llvm/lib/Support/Valgrind.cpp:37:63: error: missing '#include <stddef.h>'; 'size_t' must be declared before it is used
void llvm::sys::ValgrindDiscardTranslations(const void *Addr, size_t Len) {
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:46:23: note: declaration here is not visible
typedef __SIZE_TYPE__ size_t;
^
1 error generated.
```
rdar://88049280
The motivation for this caching wasn't clear, remove it in an effort to simplify the code and make libSupport free of global dynamic constructor. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D106206
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
llvm-svn: 250446
Remove support for Valgrind-based TSan, which hasn't been maintained for a few years. We now use the TSan annotations only if LLVM is compiled with -fsanitize=thread. We no longer need the weak function definitions as we are guaranteed that our program is linked directly with the TSan runtime. Differential Revision: http://reviews.llvm.org/D12121 llvm-svn: 245374
For projects depending on LLVM, I find it very useful to combine a release-no-asserts build of LLVM with a debug+asserts build of the dependent project. The motivation is that when developing a dependent project, you are debugging that project itself, not LLVM. In my usecase, a significant part of the runtime is spent in LLVM optimization passes, so I would like to build LLVM without assertions to get the best performance from this combination. Currently, `lib/Support/Debug.cpp` changes the set of symbols it provides depending on NDEBUG, while `include/llvm/Support/Debug.h` requires extra symbols when NDEBUG is not defined. Thus, it is not possible to enable assertions in an external project that uses facilities of `Debug.h`. This patch changes `Debug.cpp` and `Valgrind.cpp` to always define the symbols that other code may depend on when #including LLVM headers without NDEBUG. http://reviews.llvm.org/D7662 llvm-svn: 229819
That causes references to them to be weak references which can collapse to null if no definition is provided. We call these functions unconditionally, so a definition *must* be provided. Make the definitions provided in the .cpp file weak by re-declaring them as weak just prior to defining them. This should keep compilers which cannot attach the weak attribute to the definition happy while actually resolving the symbols correctly during the link. You might ask yourself upon reading this commit log: how did *any* of this work before? Well, fun story. It turns out we have some code in Support (BumpPtrAllocator) which both uses virtual dispatch and has out-of-line vtables used by that virtual dispatch. If you move the virtual dispatch into its header in *just* the right way, the optimizer gets to devirtualize, and remove all references to the vtable. Then the sad part: the references to this one vtable were the only strong symbol uses in the support library for llvm-tblgen AFAICT. At least, after doing something just like this, these symbols stopped getting their weak definition and random calls to them would segfault instead. Yay software. llvm-svn: 205137
llvm-svn: 145289
llvm-svn: 144603
link it against llvm code, by making our definitions weak. "Some users." llvm-svn: 144596