summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support/ManagedStatic.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Report fatal error in the case of out of memorySerge Pavlov2018-02-201-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-151-4/+2
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Report fatal error in the case of out of memorySerge Pavlov2018-02-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* Remove redundant includes from unittests.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320630
* [ManagedStatic] Avoid putting function pointers in template args.Benjamin Kramer2017-05-291-6/+11
| | | | | | | | This is super awkward, but GCC doesn't let us have template visible when an argument is an inline function and -fvisibility-inlines-hidden is used. llvm-svn: 304175
* Don't destroy ManagedStatics in a unit test.Benjamin Kramer2017-05-291-6/+0
| | | | | | | Turns out this is very hostile towards other unit tests running in the same process, it unregisters all flags. llvm-svn: 304165
* Try to work around MSVC being buggy. Attempt #1.Benjamin Kramer2017-05-291-1/+1
| | | | | | error C2971: 'llvm::ManagedStatic': template parameter 'Creator': 'CreateDefaultTimerGroup': a variable with non-static storage duration cannot be used as a non-type argument llvm-svn: 304157
* [ManagedStatic] Add a way to pass custom creators/deleters.Benjamin Kramer2017-05-291-0/+42
| | | | | | Also add a test case verifying that nested ManagedStatics work correctly. llvm-svn: 304155
* Re-apply r211287: Remove support for LLVM runtime multi-threading.Chandler Carruth2014-06-271-2/+0
| | | | | | | I'll fix the problems in libclang and other projects in ways that don't require <mutex> until we sort out the cygwin situation. llvm-svn: 211900
* Revert r211287, "Remove support for LLVM runtime multi-threading."NAKAMURA Takumi2014-06-241-0/+2
| | | | | | libclang still requires it on cygming, lack of incomplete <mutex>. llvm-svn: 211592
* Remove support for LLVM runtime multi-threading.Zachary Turner2014-06-191-2/+0
| | | | | | | | | | | | | After a number of previous small iterations, the functions llvm_start_multithreaded() and llvm_stop_multithreaded() have been reduced essentially to no-ops. This change removes them entirely. Reviewed by: rnk, dblaikie Differential Revision: http://reviews.llvm.org/D4216 llvm-svn: 211287
* Revert r211066, 211067, 211068, 211069, 211070.Zachary Turner2014-06-161-0/+2
| | | | | | | These were committed accidentally from the wrong branch before having a review sign-off. llvm-svn: 211072
* Remove some more code out into a separate CL.Zachary Turner2014-06-161-2/+0
| | | | llvm-svn: 211067
* [C++11] Use 'nullptr'.Craig Topper2014-06-081-5/+5
| | | | llvm-svn: 210442
* Get the unittests compiling when building with cmake and the settingDuncan Sands2013-05-141-1/+2
| | | | | | -DLLVM_ENABLE_THREADS=false. llvm-svn: 181788
* Disable Initialize.MultipleThreads test under MemorySanitizer.Evgeniy Stepanov2013-03-271-1/+1
| | | | | | Fails due to insufficient thread stack. llvm-svn: 178135
* unittests/SupportTests/Initialize.MultipleThreads: Enable ↵NAKAMURA Takumi2013-01-241-0/+2
| | | | | | | | | pthread_attr_setstack(3) only on Linux. I got blamed on darwin11; unittests/Support/ManagedStatic.cpp:35: error: 'pthread_attr_setstack' was not declared in this scope llvm-svn: 173355
* unittests/SupportTests/Initialize.MultipleThreads: Appease --vg-leak to ↵NAKAMURA Takumi2013-01-241-2/+17
| | | | | | allocate stack explicitly for glibc. llvm-svn: 173350
* Sort the #include lines for unittest/...Chandler Carruth2012-12-041-1/+1
| | | | llvm-svn: 169250
* Fix Windows build, don't try to #include <pthread.h> when we know it's notNick Lewycky2011-11-141-0/+5
| | | | | | available. llvm-svn: 144574
* Add support for tsan annotations (thread sanitizer, a valgrind-based tool).Nick Lewycky2011-11-141-0/+39
These annotations are disabled entirely when either ENABLE_THREADS is off, or building a release build. When enabled, they add calls to functions with no statements to ManagedStatic's getters. Use these annotations to inform tsan that the race used inside ManagedStatic initialization is actually benign. Thanks to Kostya Serebryany for helping write this patch! llvm-svn: 144567
OpenPOWER on IntegriCloud