|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, 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, 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, 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 |
|
| #
bbb0f2c7 |
| 11-Feb-2022 |
Arthur O'Dwyer <[email protected]> |
[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.
Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/inclu
[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.
Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/.
I've left `#include "include/x.h"` and `#include "../y.h"` alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing.
Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it.
Differential Revision: https://reviews.llvm.org/D119561
show more ...
|
|
Revision tags: 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 |
|
| #
eb8650a7 |
| 17-Nov-2021 |
Louis Dionne <[email protected]> |
[runtimes][NFC] Remove filenames at the top of the license notice
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste st
[runtimes][NFC] Remove filenames at the top of the license notice
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
show more ...
|
|
Revision tags: 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 |
|
| #
4cd6ca10 |
| 20-Apr-2021 |
Louis Dionne <[email protected]> |
[libc++] NFC: Normalize `#endif //` comment indentation
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
5601305f |
| 01-Mar-2021 |
Louis Dionne <[email protected]> |
[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept
We always build the libraries in a Standard mode that supports noexcept, so there's no need to use the _NOEXCEPT macro.
Differential Revis
[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept
We always build the libraries in a Standard mode that supports noexcept, so there's no need to use the _NOEXCEPT macro.
Differential Revision: https://reviews.llvm.org/D97700
show more ...
|
|
Revision tags: 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 |
|
| #
bc556e56 |
| 17-Dec-2020 |
Louis Dionne <[email protected]> |
[libc++/abi] Re-remove unnecessary null pointer checks from operator delete
In 7cd67904f776, we removed the unnecessary nullptr checks from the libc++abi definition of operator delete, but we forgot
[libc++/abi] Re-remove unnecessary null pointer checks from operator delete
In 7cd67904f776, we removed the unnecessary nullptr checks from the libc++abi definition of operator delete, but we forgot to update the definition in libc++ (damn code duplication!). Then, in d4a1e03c5fb5, I synced the definitions across libc++ and libc++abi, but I did it the wrong way around. I re-added the if() checks to libc++abi instead of removing them from libc++.
In ef74f0fdc339, we re-removed the if() check from operator delete, but only in libc++abi. This patch corrects this mess and removes it consistently in libc++ and libc++abi.
Differential Revision: https://reviews.llvm.org/D93473
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
527a7fdf |
| 24-Nov-2020 |
Bruce Mitchener <[email protected]> |
[libc++] Replace several uses of 0 by nullptr
Differential Revision: https://reviews.llvm.org/D43159
|
| #
a78aaa1a |
| 12-Nov-2020 |
Louis Dionne <[email protected]> |
[libc++] Factor out common logic for calling aligned allocation
There were a couple of places where we needed to call the underlying platform's aligned allocation/deallocation function. Instead of h
[libc++] Factor out common logic for calling aligned allocation
There were a couple of places where we needed to call the underlying platform's aligned allocation/deallocation function. Instead of having the same logic all over the place, extract the logic into a pair of helper functions __libcpp_aligned_alloc and __libcpp_aligned_free.
The code in libcxxabi/src/fallback_malloc.cpp looks like it could be simplified after this change -- I purposefully did not simplify it further to keep this change as straightforward as possible, since it is touching very important parts of the library.
Also, the changes in libcxx/src/new.cpp and libcxxabi/src/stdlib_new_delete.cpp are basically the same -- I just kept both source files in sync.
The underlying reason for this refactoring is to make it easier to support platforms that provide aligned allocation through C11's aligned_alloc function instead of posix_memalign. After this change, we'll only have to add support for that in a single place.
Differential Revision: https://reviews.llvm.org/D91379
show more ...
|
| #
d4a1e03c |
| 11-Nov-2020 |
Louis Dionne <[email protected]> |
[libc++] NFC: Synchronize libc++abi and libc++ new definitions
Some changes were made to the libc++abi new/delete definitions, but they were not copied back to the libc++ definition. It sucks that w
[libc++] NFC: Synchronize libc++abi and libc++ new definitions
Some changes were made to the libc++abi new/delete definitions, but they were not copied back to the libc++ definition. It sucks that we have this duplication, but for now at least let's keep them in sync.
show more ...
|
|
Revision tags: 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 |
|
| #
a4bd340b |
| 17-Apr-2019 |
Louis Dionne <[email protected]> |
[libc++][CMake] Remove unnecessary conditional for defining new handlers
It turns out that whether the new handlers should be provided is orthogonal to whether new/delete are provided in libc++ or l
[libc++][CMake] Remove unnecessary conditional for defining new handlers
It turns out that whether the new handlers should be provided is orthogonal to whether new/delete are provided in libc++ or libc++abi. The reason why I initially added this conditional is because of an incorrect understanding of the path we're taking when building on Apple platforms. In fact, we always build libc++ on top of libc++abi on Apple platforms, so we take the branch for `LIBCXX_BUILDING_LIBCXXABI` there.
llvm-svn: 358616
show more ...
|
| #
3084db3b |
| 16-Apr-2019 |
Louis Dionne <[email protected]> |
[libc++] Remove old workaround for buildit
Summary: I'm not sure what the problem was at the time, however I don't think this is necessary since buildit doesn't exist anymore.
Instead of the workar
[libc++] Remove old workaround for buildit
Summary: I'm not sure what the problem was at the time, however I don't think this is necessary since buildit doesn't exist anymore.
Instead of the workaround, the correct thing to do is to leave out the get_new_handler/set_new_handler definitions from libc++ when we're getting them from libc++abi.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60717
llvm-svn: 358518
show more ...
|
| #
f0d7d87a |
| 21-Mar-2019 |
Louis Dionne <[email protected]> |
[NFC][libc++] Reindent #ifdefs
I don't understand why we don't always do that. We do it for normal `if`s in the code, but not for preprocessor `if`s? It's a lot more readable when indented properly.
[NFC][libc++] Reindent #ifdefs
I don't understand why we don't always do that. We do it for normal `if`s in the code, but not for preprocessor `if`s? It's a lot more readable when indented properly.
llvm-svn: 356693
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
| #
e69290dc |
| 05-Mar-2019 |
Eric Fiselier <[email protected]> |
Make VCRuntime ABI configuration a first-class option.
Summary: On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and anothe
Make VCRuntime ABI configuration a first-class option.
Summary: On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and another which doesn't. Using `vcruntime` allows interoperability which programs compiled against the MSVC STL, and should be preferred whenever possible.
When deferring to `vcruntime` much of the ABI we provide changes. Including the layout of `<stdexcept>` types, their vtables, and how the linkage of their members.
This patch introduces the `_LIBCPP_ABI_VCRUNTIME` macro to denote this configuration. It also cleans up the existing configuration for using `vcruntime`.
This cleanup lays the groundwork for fixing a number of ABI and interoperability bugs in `<stdexcept>`.
Reviewers: thomasanderson, ldionne, smeenai
Reviewed By: smeenai
Subscribers: jdoerfert, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D58942
llvm-svn: 355366
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2 |
|
| #
3663f26f |
| 30-Jan-2019 |
Thomas Anderson <[email protected]> |
[libc++] Explicitly initialize std::nothrow
When building on Windows without libc++abi, this change fixes a build error of the form:
src/new.cpp(38,17): error: chosen constructor is explicit i
[libc++] Explicitly initialize std::nothrow
When building on Windows without libc++abi, this change fixes a build error of the form:
src/new.cpp(38,17): error: chosen constructor is explicit in copy-initialization const nothrow_t nothrow = {}; include/vcruntime_new.h(53,22): note: explicit constructor declared here explicit nothrow_t() = default;
Differential Revision: https://reviews.llvm.org/D57351
llvm-svn: 352648
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc1 |
|
| #
57b08b09 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions.
We understand that
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions.
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: 351648
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
42f9868c |
| 11-Oct-2018 |
Eric Fiselier <[email protected]> |
Distinguish between library and language support for aligned allocation.
There are two cases: 1. The library has all it needs to provide align_val_t and the new/delete overloads needed to support al
Distinguish between library and language support for aligned allocation.
There are two cases: 1. The library has all it needs to provide align_val_t and the new/delete overloads needed to support aligned allocation. 2. The compiler has actually turned the language feature on.
There are times where libc++ needs to distinguish between the two.
This patch adds the additional macro _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1) does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the compiler has not enabled the language feature.
Additionally this patch cleans up a number of other macros related to detection of aligned allocation machinery.
llvm-svn: 344207
show more ...
|
| #
7cd67904 |
| 01-Oct-2018 |
Fangrui Song <[email protected]> |
Remove redundant null pointer check in operator delete
Summary: C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function
If ptr is a null pointer, no action
Remove redundant null pointer check in operator delete
Summary: C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occur.
_aligned_free on MSDN:
If memblock is a NULL pointer, this function simply performs no actions.
Reviewers: EricWF, mclow.lists, khng300, hotpxl
Reviewed By: mclow.lists, khng300, hotpxl
Subscribers: lichray, llvm-commits, hotpxl, khng300, christof, ldionne, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52401
llvm-svn: 343503
show more ...
|
| #
3c3e1c62 |
| 25-Sep-2018 |
Louis Dionne <[email protected]> |
Revert r342936 "Remove redundant null pointer check in operator delete"
A review for the change was opened in https://reviews.llvm.org/D52401 but the change was committed before being approved by an
Revert r342936 "Remove redundant null pointer check in operator delete"
A review for the change was opened in https://reviews.llvm.org/D52401 but the change was committed before being approved by any of the code owners for libc++.
llvm-svn: 342938
show more ...
|
| #
6da5366e |
| 25-Sep-2018 |
Fangrui Song <[email protected]> |
Remove redundant null pointer check in operator delete
C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occ
Remove redundant null pointer check in operator delete
C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occur.
_aligned_free on MSDN:
If memblock is a NULL pointer, this function simply performs no actions.
Reviewers: EricWF, mclow.lists
Subscribers: christof, ldionne, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52401
llvm-svn: 342936
show more ...
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1 |
|
| #
c8e84ff2 |
| 01-Aug-2018 |
Louis Dionne <[email protected]> |
[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY
Summary: As suggested by Marshall in https://reviews.llvm.org/D49914
Reviewers: mclow.lists, EricWF
[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY
Summary: As suggested by Marshall in https://reviews.llvm.org/D49914
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50008
llvm-svn: 338475
show more ...
|
|
Revision tags: 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, 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 |
|
| #
492d7134 |
| 09-Oct-2017 |
Shoaib Meenai <[email protected]> |
[libc++] Support Microsoft ABI without vcruntime headers
The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by
[libc++] Support Microsoft ABI without vcruntime headers
The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions.
Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details.
Differential Revision: https://reviews.llvm.org/D38522
llvm-svn: 315234
show more ...
|
| #
fbfaec70 |
| 19-Sep-2017 |
Weiming Zhao <[email protected]> |
[libc++] Replace __sync_* functions with __libcpp_atomic_* functions
Summary: This patch replaces __sync_* with __libcpp_atomic_* and adds a wrapper function for __atomic_exchange to support _LIBCPP
[libc++] Replace __sync_* functions with __libcpp_atomic_* functions
Summary: This patch replaces __sync_* with __libcpp_atomic_* and adds a wrapper function for __atomic_exchange to support _LIBCPP_HAS_NO_THREADS.
Reviewers: EricWF, jroelofs, mclow.lists, compnerd
Reviewed By: EricWF, compnerd
Subscribers: compnerd, efriedma, cfe-commits, joerg, llvm-commits
Differential Revision: https://reviews.llvm.org/D35235
llvm-svn: 313694
show more ...
|
|
Revision tags: 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 |
|
| #
1ec02625 |
| 31-May-2017 |
Eric Fiselier <[email protected]> |
Fix Libc++ build with MinGW64
Summary: This patch corrects the build errors I encountered when building on MinGW64.
Reviewers: mati865, rnk, compnerd, smeenai, bcraig
Reviewed By: mati865, smeenai
Fix Libc++ build with MinGW64
Summary: This patch corrects the build errors I encountered when building on MinGW64.
Reviewers: mati865, rnk, compnerd, smeenai, bcraig
Reviewed By: mati865, smeenai
Subscribers: martell, chapuni, cfe-commits
Differential Revision: https://reviews.llvm.org/D33082
llvm-svn: 304360
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4 |
|
| #
3499263c |
| 02-Mar-2017 |
Eric Fiselier <[email protected]> |
[libc++] Add option to disable new/delete overloads when libc++abi provides them.
Summary: Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is
[libc++] Add option to disable new/delete overloads when libc++abi provides them.
Summary: Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them.
This patch adds the CMake option `-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS` which defaults no `ON` unless `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON` is specified.
Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, mgorny, rmaprath
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30516
llvm-svn: 296802
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc3 |
|
| #
637160c5 |
| 10-Feb-2017 |
Eric Fiselier <[email protected]> |
Attempt to fix Apple buildit bots
llvm-svn: 294731
|
| #
d22c9dc4 |
| 10-Feb-2017 |
Eric Fiselier <[email protected]> |
Recommit "Split exception.cpp and new.cpp implementation into different files for different runtimes."
This recommits r294707 with additional fixes. The main difference is libc++ now correctly build
Recommit "Split exception.cpp and new.cpp implementation into different files for different runtimes."
This recommits r294707 with additional fixes. The main difference is libc++ now correctly builds without any ABI library.
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files, roughly one per implementation. Additionally it moves the definitions of exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration. This configuration may still be used by Apple internally but there are no other possible users. If it turns out that Apple still uses this configuration internally I will re-add it in a later commit. See http://llvm.org/PR31904.
llvm-svn: 294730
show more ...
|