Summary:
Also, there are no exported character type tables from Musl so we have to
Fallback to the standard functions. This reduces the number of libcxx's
test-suite failures down to ~130 for MIPS. Most of the remaining failures
come from the atomics (due to the lack of 8-byte atomic-ops in MIPS32) and
thread tests.
Reviewers: mclow.lists, EricWF, dalias, jroelofs
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D14926
llvm-svn: 253972
The initial buildbot run found a few missing bits in the initial XFAIL list
for the no-exceptions libc++ variant. These discrepancies are as follows:
[1] Following two tests need XFAILs on the no-exceptions library variant.
My local runs had these two disabled for other reasons (unsupported):
- localization/locales/locale/locale.cons/char_pointer.pass.cpp
- numerics/complex.number/complex.ops/complex_divide_complex.pass.cpp
[2] These three does not need XFAILs, they were failing on my local runs for
other reasons:
- depr/depr.c.headers/uchar_h.pass.cpp
- input.output/iostreams.base/ios/basic.ios.members/copyfmt.pass.cpp
- .../category.collate/locale.collate.byname/transform.pass.cpp
(these are failing on my box for the default build as well)
The current patch fixes both the cases above. Additionally, I've run the
following scan to make sure I've covered all the cases:
> grep ' catch \| try \| throw ' -R . | perl -pe 's|(.*?):.*|\1|' | sort | \
uniq > 1.txt
> grep 'libcpp-no-exceptions' -R . | perl -pe 's|(.*?):.*|\1|' | sort | \
uniq > 2.txt
> diff 1.txt 2.txt
This showed up a few extra interesting cases:
[3] These two tests do not use try/catch/throw statements, but they fail at
runtime. Need to be investigated, I've left the XFAILs in.
- std/thread/futures/futures.shared_future/dtor.pass.cpp
- std/thread/futures/futures.unique_future/dtor.pass.cpp
[4] These tests use a macro named TEST_HAS_NO_EXCEPTIONS to conditionally
exclude try/catch/throw statements when running without exceptions. I'm not
entirely sure why this was needed (AFAIK, we didn't have a no-exceptions
library build before). The macro's defintion is quite similar to that of
_LIBCPP_NO_EXCEPTIONS. I will investigate if this can be reused for my test
fixes or if it should be replaced with _LIBCPP_NO_EXCEPTIONS.
- std/experimental/any/*
Change-Id: I9ad1e0edd78f305406eaa0ab148b1ab693f7e26a
llvm-svn: 252870
Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.
This patch adds XFAILS to all those tests that are currently failing
on the new -fno-exceptions library variant. Follow-up patches will
update the tests (progressively) to cope with the new library variant.
Change-Id: I4b801bd8d8e4fe7193df9e55f39f1f393a8ba81a
llvm-svn: 252598
Summary:
This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the
building of libcxx with the Musl C library. The option is necessary as
Musl does not provide any predefined macro in order to test for its
presence, like GLIBC. Most of the changes specify the correct path to
choose through the various #if/#else constructs in the locale code.
Depends on D13407.
Reviewers: mclow.lists, jroelofs, EricWF
Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13673
llvm-svn: 252457
This change moves visibility attributes from out-of-class method
definitions to in-class declaration. This is needed for a switch to
attribute((internal_linkage)) (see http://reviews.llvm.org/D13925)
which can only appear on the first declaration.
This change does not touch istream/ostream/streambuf. They are
handled separately in http://reviews.llvm.org/D14409.
llvm-svn: 252385
Allow deque and deque::iterator instantiation with incomplete element
type. This is an ABI breaking change, and it is only enabled if
LIBCXX_ABI_VERSION >= 2 or LIBCXX_ABI_UNSTABLE=ON.
llvm-svn: 252350
This change caused problems when building code like povray that:
a) uses 'using namespace std;'
b) is built on an environment where the C library provides the "wrong"
(non-const-correct) interface for the str* functions
c) makes an unqualified call to one of those str* functions
A patch is out for review to add a facility to fix this (and to give the
correct signatures for these functions whenever possible, even when the C
library does not do so). This revert is expected to be temporary.
llvm-svn: 251665
Marshall Clow