------------------------------------------------------------------------
r196058 | marshall | 2013-12-01 19:24:33 -0800 (Sun, 01 Dec 2013) | 1 line
Fix for PRPR17934; based on a fix suggested by Peter Sommerlad
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@197133 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r196058 | marshall | 2013-12-01 19:24:33 -0800 (Sun, 01 Dec 2013) | 1 line
Fix for PRPR17934; based on a fix suggested by Peter Sommerlad
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@197013 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r196058 | marshall | 2013-12-01 19:24:33 -0800 (Sun, 01 Dec 2013) | 1 line
Fix for PRPR17934; based on a fix suggested by Peter Sommerlad
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@196077 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r195143 | marshall | 2013-11-19 11:14:27 -0800 (Tue, 19 Nov 2013) | 1 line
Fix a test that I broke over the weekend
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@195223 91177308-0d34-0410-b5e6-96231b3b80d8
pair, and a couple of pair-like implementation detail types. The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.
Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors. Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm). This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.
Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members. However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).
During this work a bug was also found and fixed in
is_trivially_constructible.
And there is a minor drive-by fix in <__config> regarding
__type_visibility__.
A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11. This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@194536 91177308-0d34-0410-b5e6-96231b3b80d8
http://lab.llvm.org:8013/builders/libcxx_clang-x86_64-darwin11-RA
lit.py: <string>:230: note: inferred use_system_lib as: False
lit.py: <string>:247: fatal: C++ ABI setting None unsupported for tests
cxx_abi is geting set to None, and the lit script errors out shortly after
that. This patch changes the default of cxx_abi from None to 'libcxxabi'.
This is likely not the right way to fix this problem. However it gets the
buildbot running again. Improvements to this fix are welcome.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192609 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192075 91177308-0d34-0410-b5e6-96231b3b80d8
iterator, allocator) constructor with the intention of it being
implicitly converted to the allocator type, it is possible for overload
resolution to favour the (iterator, iterator, enable_if) constructor.
Eliminate this possibility by moving the enable_if to one of the
existing arguments and removing the third argument.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191145 91177308-0d34-0410-b5e6-96231b3b80d8
- The lit builtin XFAIL handling is more restrictive than what we were
previously using, and for now I'd rather keep the lit one restrictive.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@189692 91177308-0d34-0410-b5e6-96231b3b80d8
