| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290849
|
|
|
|
| |
llvm-svn: 290841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`__libcpp_refstring` currently has two different definitions. First there is the complete definition in `<__refstring>` but there is also a second in `<stdexcept>`. The historical reason for this split is because both libc++ and libc++abi need to see the inline definitions of __libcpp_refstrings methods, but the `<stdexcept>` header doesn't. However this is an ODR violation and breaks the modules build.
This patch fixes the issue by creating a single class definition in `<stdexcept>` and changing `<__refstring>` to contain only the inline method definitions. This way both `libcxx/src/stdexcept.cpp` and `libcxxabi/src/stdexcept.cpp` see the same declaration in `<stdexcept>` and definitions in `<__refstring>`
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25603
llvm-svn: 285100
|
|
|
|
|
|
| |
Should fix the xcode libc++ build.
llvm-svn: 250508
|
|
|
|
|
|
|
|
|
| |
This was put in to get libc++ building without libcxxabi. We now have
macros that show that we are building against libcxxabi so use that
instead. This guards against existing but broken cxxabi.h headers on the
system.
llvm-svn: 250507
|
|
|
|
|
|
|
|
|
| |
compatibility to libstdc++. Move the implementation into a header for
easier sharing with libc++abi. Merge a number of improvements from that
version. Provide a POD definition for <stdexcept>'s public use to avoid
cast dances. Discussed with Marshall Clow.
llvm-svn: 207695
|
|
|
|
|
|
| |
Change suggested by Joerg Sonnenberger!
llvm-svn: 199500
|
|
|
|
|
|
|
|
|
|
| |
The __sync_add_and_fetch() builtin parameter is volatile but clang has
'different' type checking and ends up accepting this code.
Undo the C++ cast from r198505 to get libc++/LLVM building with g++ while this
is investigated.
llvm-svn: 199494
|
|
|
|
|
|
| |
address. Restores the assembly of before r198504.
llvm-svn: 198698
|
|
|
|
| |
llvm-svn: 198505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linking against libstdc++, rather than libsupc++, is probably better
for people who need to link against clients of libstdc++. Because
libsupc++ is provided only as a static library, its globals are not
shared between the static library and the copy linked into libstdc++.
This has been found to cause at least one test failure.
This also removes a number of symbols which were multiply defined
between libstdc++ and libc++, only when linking with libstdc++.
Differential Revision: http://llvm-reviews.chandlerc.com/D1825
llvm-svn: 192075
|
|
|
|
|
|
| |
which does not support #pragma visibility.
llvm-svn: 191988
|
|
|
|
| |
llvm-svn: 189046
|
|
|
|
|
|
| |
'len strlen(msg)', so we can use memcpy() instead of strcpy().
llvm-svn: 185274
|
|
|
|
| |
llvm-svn: 177297
|
|
|
|
| |
llvm-svn: 163120
|
|
|
|
|
|
| |
bits for 64 bit targets. This is controls the data layout of all exceptions defined in <stdexcept>. This aligns the ABI with that of gcc-4.2.
llvm-svn: 161497
|
|
|
|
|
|
|
|
| |
out of the box on Linux systems. If you're building against libc++abi, you
still need to make sure it can find <cxxabi.h> so it knows not to export
symbols which libc++abi provides.
llvm-svn: 155091
|
|
|
|
| |
llvm-svn: 150835
|
|
|
|
| |
llvm-svn: 132137
|
|
|
|
| |
llvm-svn: 119395
|
|
|
|
| |
llvm-svn: 113061
|
|
|
|
|
|
| |
accepted except there were some bug fixes needed in <locale> for the __nolocale_* series. For the apple branch I ended up using templates instead of the var_args solution because it seemed both safer and more efficient.
llvm-svn: 104516
|
|
|
|
| |
llvm-svn: 103516
|
|
llvm-svn: 103490
|