Revision tags: 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 |
|
#
513f89dc |
| 03-Oct-2022 |
Michael Holman <michael.holman@microsoft.com> |
Add functionality to load dynamic libraries temporarily
Previously, it was possible to load dynamic libraries which would be unloaded on llvm_shutdown(), but recently ManagedStatic removal changed t
Add functionality to load dynamic libraries temporarily
Previously, it was possible to load dynamic libraries which would be unloaded on llvm_shutdown(), but recently ManagedStatic removal changed this so that loaded libraries really can't ever be unloaded. This functionality was very useful, and so to add it back in a more explicit way, I've added new getLibrary() and closeLibrary() methods to allow callers to use the very convenient platform independent abstraction that LLVM has for dynamic libraries.
As a specific use case, the onnx-mlir project was using this functionality with an API that allows instancing LLVM so you can compile a shared library, and then load that library, and eventually close the instance (and library) and compile something else. This change to llvm_shutdown causes libraries to leak and also locks the libraries for the entire duration of the program which prevents reusing library names.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D134763
show more ...
|
Revision tags: 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 |
|
#
ebbbd93e |
| 29-Jun-2022 |
Nicolai Hähnle <nicolai.haehnle@amd.com> |
ManagedStatic: remove from DynamicLibrary
v2: - fix Windows build issues
Differential Revision: https://reviews.llvm.org/D129127
|
#
5c7c8388 |
| 03-Aug-2022 |
Nicolai Hähnle <nicolai.haehnle@amd.com> |
Revert "ManagedStatic: remove from DynamicLibrary"
This reverts commit 38817af6a7271aee0581c56eaea44b8c4cf5ecc7.
Buildbots report a Windows build error. Revert until I can look at it more carefully.
|
#
38817af6 |
| 29-Jun-2022 |
Nicolai Hähnle <nicolai.haehnle@amd.com> |
ManagedStatic: remove from DynamicLibrary
Differential Revision: https://reviews.llvm.org/D129127
|
Revision tags: llvmorg-14.0.6 |
|
#
6c396875 |
| 13-Jun-2022 |
Kazu Hirata <kazu@google.com> |
[Support] Use default member initialization (NFC)
Identified with modernize-use-default-member-init.
|
Revision tags: 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 |
|
#
fbbc41f8 |
| 09-Mar-2022 |
serge-sans-paille <sguelton@redhat.com> |
Cleanup include: TableGen
This also includes a few cleanup from Support.
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.l
Cleanup include: TableGen
This also includes a few cleanup from Support.
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121331
show more ...
|
Revision tags: 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 |
|
#
c1f068b8 |
| 01-Jul-2021 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
[flang] Revert "PoC for Flang Driver Plugins"
This patch has not been reviewed and was commited by accident.
This reverts commit 788a5d4afe6407e647454a9832a7b4a27fba06bf.
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
#
788a5d4a |
| 23-Jun-2021 |
Stuart Ellis <stuart.ellis@arm.com> |
PoC for Flang Driver Plugins
|
Revision tags: 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 |
|
#
0164d546 |
| 27-Jan-2021 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
[Support] Add some missing namespace closure comments. NFCI.
Fixes some clang-tidy warnings.
|
Revision tags: llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
#
88572024 |
| 20-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use llvm::find (NFC)
|
Revision tags: 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 |
|
#
712e8d29 |
| 29-Apr-2018 |
Nico Weber <nicolasweber@gmx.de> |
s/LLVM_ON_WIN32/_WIN32/, llvm
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of
s/LLVM_ON_WIN32/_WIN32/, llvm
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change.
This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet.
llvm-svn: 331127
show more ...
|
Revision tags: 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, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, 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 |
|
#
5fdd2cba |
| 12-Jul-2017 |
Frederich Munch <colsebas@hotmail.com> |
Allow clients to specify search order of DynamicLibraries.
Summary: Different JITs and other clients of LLVM may have different needs in how symbol resolution should occur.
Reviewers: v.g.vassilev,
Allow clients to specify search order of DynamicLibraries.
Summary: Different JITs and other clients of LLVM may have different needs in how symbol resolution should occur.
Reviewers: v.g.vassilev, lhames, karies
Reviewed By: v.g.vassilev
Subscribers: pcanal, llvm-commits
Differential Revision: https://reviews.llvm.org/D33529
llvm-svn: 307849
show more ...
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
#
8c3735e5 |
| 26-May-2017 |
Frederich Munch <colsebas@hotmail.com> |
Fix the ManagedStatic list ordering when using DynamicLibrary::addPermanentLibrary.
Summary: r295737 included a fix for leaking libraries loaded via. DynamicLibrary::addPermanentLibrary. This create
Fix the ManagedStatic list ordering when using DynamicLibrary::addPermanentLibrary.
Summary: r295737 included a fix for leaking libraries loaded via. DynamicLibrary::addPermanentLibrary. This created a problem where static constructors in a library could insert llvm::ManagedStatic objects before DynamicLibrary would register it's own ManagedStatic, meaning a crash could occur at shutdown.
r301562 exasperated this problem by cleaning up the DynamicLibrary ManagedStatic during llvm_shutdown.
Reviewers: v.g.vassilev, lhames, efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33581
llvm-svn: 304027
show more ...
|
Revision tags: llvmorg-4.0.1-rc1 |
|
#
c1db8cf9 |
| 27-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.
Summary: This was mostly affecting usage of the JIT, whe
Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.
Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions:
JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv
Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix.
Reviewers: chapuni, v.g.vassilev, lhames
Reviewed By: lhames
Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D30107
llvm-svn: 301562
show more ...
|
#
fd96d5e1 |
| 24-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Revert "Refactor DynamicLibrary so searching for a symbol will have a defined order" The i686-mingw32-RA-on-linux bot is still having errors.
This reverts commit r301236.
llvm-svn: 301240
|
#
70c377a3 |
| 24-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.
Summary: This was mostly affecting usage of the JIT, whe
Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.
Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions:
JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv
Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix.
Reviewers: chapuni, v.g.vassilev, lhames
Reviewed By: lhames
Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D30107
llvm-svn: 301236
show more ...
|
#
b8c236a6 |
| 24-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Revert "Refactor DynamicLibrary so searching for a symbol will have a defined order.” The changes are causing the i686-mingw32 build to fail.
This reverts commit r301153, and the changes for a separ
Revert "Refactor DynamicLibrary so searching for a symbol will have a defined order.” The changes are causing the i686-mingw32 build to fail.
This reverts commit r301153, and the changes for a separate warning on i686-mingw32 in r301155 and r301156.
llvm-svn: 301157
show more ...
|
#
799259f3 |
| 24-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Fix warning converting from boolean to pointer introduced in r301153.
This reverts commit r301155, which was incorrect.
llvm-svn: 301156
|
#
c152a963 |
| 24-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Fix warning converting from void* to boolean introduced in r301153.
llvm-svn: 301155
|
#
9f40457d |
| 24-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.
Summary: This was mostly affecting usage of the JIT, whe
Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.
Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions:
JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv
Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix.
Reviewers: chapuni, v.g.vassilev, lhames
Reviewed By: lhames
Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D30107
llvm-svn: 301153
show more ...
|
#
5b088702 |
| 21-Apr-2017 |
Frederich Munch <colsebas@hotmail.com> |
[Test commit] Remove extra newline.
llvm-svn: 301046
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4 |
|
#
7f1c255d |
| 02-Mar-2017 |
Vassil Vassilev <v.g.vassilev@gmail.com> |
Reland r296442 with modifications reverted in r296463.
Original commit message:
"Allow externally dlopen-ed libraries to be registered as permanent libraries.
This is also useful in cases when llv
Reland r296442 with modifications reverted in r296463.
Original commit message:
"Allow externally dlopen-ed libraries to be registered as permanent libraries.
This is also useful in cases when llvm is in a shared library. First we dlopen the llvm shared library and then we register it as a permanent library in order to keep the JIT and other services working.
Patch reviewed by Vedant Kumar (D29955)!"
llvm-svn: 296774
show more ...
|
Revision tags: llvmorg-4.0.0-rc3 |
|
#
3d369cba |
| 28-Feb-2017 |
NAKAMURA Takumi <geek4civic@gmail.com> |
Revert r296442 (and r296443), "Allow externally dlopen-ed libraries to be registered as permanent libraries."
It broke clang/test/Analysis/checker-plugins.c
llvm-svn: 296463
|
#
44693083 |
| 28-Feb-2017 |
Vassil Vassilev <v.g.vassilev@gmail.com> |
Allow externally dlopen-ed libraries to be registered as permanent libraries.
This is also useful in cases when llvm is in a shared library. First we dlopen the llvm shared library and then we regis
Allow externally dlopen-ed libraries to be registered as permanent libraries.
This is also useful in cases when llvm is in a shared library. First we dlopen the llvm shared library and then we register it as a permanent library in order to keep the JIT and other services working.
Patch reviewed by Vedant Kumar (D29955)!
llvm-svn: 296442
show more ...
|