|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
| #
89e6a288 |
| 30-Aug-2024 |
Daniil Fukalov <dfukalov@gmail.com> |
[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial si
[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.
show more ...
|
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo
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
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3 |
|
| #
76d8ccee |
| 20-Feb-2018 |
Serge Pavlov <sepavloff@gmail.com> |
Report fatal error in the case of out of memory
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 mem
Report fatal error in the case of out of memory
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
show more ...
|
| #
45000019 |
| 15-Feb-2018 |
Serge Pavlov <sepavloff@gmail.com> |
Revert r325224 "Report fatal error in the case of out of memory"
It caused fails on some buildbots.
llvm-svn: 325227
|
| #
431502a6 |
| 15-Feb-2018 |
Serge Pavlov <sepavloff@gmail.com> |
Report fatal error in the case of out of memory
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
Report fatal error in the case of out of memory
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
show more ...
|
|
Revision tags: llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
| #
5c0ab473 |
| 13-Dec-2017 |
Michael Zolotukhin <mzolotukhin@apple.com> |
Remove redundant includes from unittests.
llvm-svn: 320630
|
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
74de0803 |
| 29-May-2017 |
Benjamin Kramer <benny.kra@googlemail.com> |
[ManagedStatic] Avoid putting function pointers in template args.
This is super awkward, but GCC doesn't let us have template visible when
an argument is an inline function and -fvisibility-inlines-
[ManagedStatic] Avoid putting function pointers in template args.
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
show more ...
|
| #
ca693ed7 |
| 29-May-2017 |
Benjamin Kramer <benny.kra@googlemail.com> |
Don't destroy ManagedStatics in a unit test.
Turns out this is very hostile towards other unit tests running in the
same process, it unregisters all flags.
llvm-svn: 304165
|
| #
2a441a52 |
| 29-May-2017 |
Benjamin Kramer <benny.kra@googlemail.com> |
Try to work around MSVC being buggy. Attempt #1.
error C2971: 'llvm::ManagedStatic': template parameter 'Creator': 'CreateDefaultTimerGroup': a variable with non-static storage duration cannot be us
Try to work around MSVC being buggy. Attempt #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
show more ...
|
| #
1533eda1 |
| 29-May-2017 |
Benjamin Kramer <benny.kra@googlemail.com> |
[ManagedStatic] Add a way to pass custom creators/deleters.
Also add a test case verifying that nested ManagedStatics work correctly.
llvm-svn: 304155
|
|
Revision tags: llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
| #
39cd216f |
| 27-Jun-2014 |
Chandler Carruth <chandlerc@gmail.com> |
Re-apply r211287: Remove support for LLVM runtime multi-threading.
I'll fix the problems in libclang and other projects in ways that don't
require <mutex> until we sort out the cygwin situation.
ll
Re-apply r211287: Remove support for LLVM runtime multi-threading.
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
show more ...
|
| #
104e5f67 |
| 24-Jun-2014 |
NAKAMURA Takumi <geek4civic@gmail.com> |
Revert r211287, "Remove support for LLVM runtime multi-threading."
libclang still requires it on cygming, lack of incomplete <mutex>.
llvm-svn: 211592
|
| #
9c9710ea |
| 19-Jun-2014 |
Zachary Turner <zturner@google.com> |
Remove support for LLVM runtime multi-threading.
After a number of previous small iterations, the functions
llvm_start_multithreaded() and llvm_stop_multithreaded() have
been reduced essentially to
Remove support for LLVM runtime multi-threading.
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
show more ...
|
| #
ccbf3d01 |
| 16-Jun-2014 |
Zachary Turner <zturner@google.com> |
Revert r211066, 211067, 211068, 211069, 211070.
These were committed accidentally from the wrong branch before having
a review sign-off.
llvm-svn: 211072
|
| #
0f2c641f |
| 16-Jun-2014 |
Zachary Turner <zturner@google.com> |
Remove some more code out into a separate CL.
llvm-svn: 211067
|
| #
66f09ad0 |
| 08-Jun-2014 |
Craig Topper <craig.topper@gmail.com> |
[C++11] Use 'nullptr'.
llvm-svn: 210442
|
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1, llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1, llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2 |
|
| #
b33790d8 |
| 14-May-2013 |
Duncan Sands <baldrick@free.fr> |
Get the unittests compiling when building with cmake and the setting
-DLLVM_ENABLE_THREADS=false.
llvm-svn: 181788
|
|
Revision tags: llvmorg-3.3.0-rc1 |
|
| #
11820f4b |
| 27-Mar-2013 |
Evgeniy Stepanov <eugeni.stepanov@gmail.com> |
Disable Initialize.MultipleThreads test under MemorySanitizer.
Fails due to insufficient thread stack.
llvm-svn: 178135
|
| #
cbc86bcb |
| 24-Jan-2013 |
NAKAMURA Takumi <geek4civic@gmail.com> |
unittests/SupportTests/Initialize.MultipleThreads: Enable pthread_attr_setstack(3) only on Linux.
I got blamed on darwin11;
unittests/Support/ManagedStatic.cpp:35: error: 'pthread_attr_setstack' was
unittests/SupportTests/Initialize.MultipleThreads: Enable 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
show more ...
|
| #
2998dcba |
| 24-Jan-2013 |
NAKAMURA Takumi <geek4civic@gmail.com> |
unittests/SupportTests/Initialize.MultipleThreads: Appease --vg-leak to allocate stack explicitly for glibc.
llvm-svn: 173350
|
|
Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3 |
|
| #
130cec21 |
| 04-Dec-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Sort the #include lines for unittest/...
llvm-svn: 169250
|
|
Revision tags: llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1, llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1, llvmorg-3.0.0, llvmorg-3.0.0-rc4 |
|
| #
e5dc7550 |
| 14-Nov-2011 |
Nick Lewycky <nicholas@mxc.ca> |
Fix Windows build, don't try to #include <pthread.h> when we know it's not
available.
llvm-svn: 144574
|
| #
fe856110 |
| 14-Nov-2011 |
Nick Lewycky <nicholas@mxc.ca> |
Add support for tsan annotations (thread sanitizer, a valgrind-based tool).
These annotations are disabled entirely when either ENABLE_THREADS is off, or
building a release build. When enabled, they
Add support for tsan annotations (thread sanitizer, a valgrind-based tool).
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
show more ...
|