| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|