Signals may result in nanosleep returning with only some of the
requested sleeping performed.
Utilize nanosleep's "time-remaining" out parameter to continue sleeping
when this occurs.
llvm-svn: 210210
Make sure we appropriately retry calls to read if the return result is
less than what we asked for.
Additionally, check and handle IO errors: EINTR results in the read
operation getting restarted; other errors turn into exceptions.
llvm-svn: 210061
random_device::random_device(const string&) wrongly assumes that open
can only validly return a file descriptor greater than zero.
This results in random_device believing that it didn't successfully open
the device causing it to throw in it's constructor, this ends up leaking
a file descriptor.
The fix is simple, don't error on file descriptors which are zero.
llvm-svn: 210060
[syserr.errcat.objects]p4 specifies that
system_category().default_error_condition(ev) map to
error_condition(posv, generic_category()) if ev could map to a POSIX
errno.
Linux reserves up to and including 4095 for errno values, use this as a
bound.
This fixes syserr.errcat.objects/system_category.pass.cpp on Linux.
llvm-svn: 209795
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
This is as straightforward as it sounds, a renamed from shared_mutex to
shared_timed_mutex.
Note that libcxx .dylib and .so files built with c++14 support need to
be rebuilt.
llvm-svn: 204078
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
We should check defined(__clang__) before the usage of the
clang diagnostic pragmas.
The [-Wswitch] warning in src/future.cpp should be ignored.
As the result, the equivalent GCC pragma is added.
llvm-svn: 197314
functions in src/support/win32/locale_win32.cpp and locale_win32.h,
calling upon vsnprintf for which there is a MingW correct alternative.
Note! __USE_MINGW_ANSI_STDIO is not modified in this patch. In order to
use the __mingw version it must be defined before including the MingW
headers.
llvm-svn: 195044
libsupc++ does not implement the dependent EH ABI and the
functionality it uses to implement std::exception_ptr (which it
declares as an alias of std::__exception_ptr::exception_ptr) is not
directly exported to clients. So we have little choice but to hijack
std::__exception_ptr::exception_ptr's (which fortunately has the
same layout as our std::exception_ptr) copy constructor, assignment
operator and destructor (which are part of its stable ABI), and its
rethrow_exception(std::__exception_ptr::exception_ptr) function.
Also, remove some out of date comments.
Differential Revision: http://llvm-reviews.chandlerc.com/D1826
llvm-svn: 192076
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
The remaining multiple definitions were flushed out by attempting to
link libsupc++ and libc++ into the same executable with --whole-archive,
e.g.
clang++ -I../llvm/projects/libcxx/include -nodefaultlibs -Wl,--whole-archive lib/libc++.a /usr/lib/gcc/x86_64-linux-gnu/4.6/libsupc++.a -Wl,--no-whole-archive -lgcc -lgcc_s -lc -lpthread -lrt
(The same technique was used to flush out multiple definitions in
libstdc++.)
Differential Revision: http://llvm-reviews.chandlerc.com/D1824
llvm-svn: 192074
The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.
This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }
to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }
Howard: Thanks for all the comments regarding the default visibility
tag on the definition. I agree it isn't needed, and that there are lots
of other places where it is missing. That being said, I'm not wanting
to rock the boat on that issue right now. So I've added it back to the
definition via _LIBCPP_FUNC_VIS. A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other.
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case. The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.
llvm-svn: 192007
libsupc++ in typeinfo.cpp, bringing it into agreement with
exception.cpp. This fixes link errors due to duplicate symbols from
this translation unit.
llvm-svn: 191397
1. I had been detecting and trapping iterator == and \!= among iterators
in different containers as an error. But the trapping itself is actually
an error.
Consider:
#include <iostream>
#include <vector>
#include <algorithm>
template <class C>
void
display(const C& c)
{
std::cout << "{";
bool first = true;
for (const auto& x : c)
{
if (\!first)
std::cout << ", ";
first = false;
std::cout << x;
}
std::cout << "}\n";
}
int
main()
{
typedef std::vector<int> V;
V v1 = {1, 3, 5};
V v2 = {2, 4, 6};
display(v1);
display(v2);
V::iterator i = std::find(v1.begin(), v1.end(), 1);
V::iterator j = std::find(v2.begin(), v2.end(), 2);
if (*i == *j)
i = j; // perfectly legal
// ...
if (i \!= j) // the only way to check
v2.push_back(*i);
display(v1);
display(v2);
}
It is legal to assign an iterator from one container to another of the
same type. This is required to work. One might want to test whether or
not such an assignment had been made. The way one performs such a check
is using the iterator's ==, \!= operator. This is a logical and necessary
function and does not constitute an error.
2. I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
This caused a problem in several of the libc++ tests.
Fixed.
3. There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
std::basic_string is inoperable. std::basic_string uses __wrap_iterator
to implement its iterators. __wrap_iterator has been rigged up in debug
mode to support vector. But string hasn't been rigged up yet. This means
that one gets false positives when using std::string in debug mode. I've
upped std::string's priority in www/debug_mode.html.
llvm-svn: 187636
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
llvm-svn: 187593
code to specify what version of POSIX the system should provide. If
you want to check what version of POSIX is actually available, you're
supposed to test _POSIX_VERSION.
However, since sysconf() has been in POSIX since 1995, it's probably
safe to assume it's available on any system with a C++11 compiler,
especially if _SC_NPROCESSORS_ONLN is defined too. So no point in a
complicated preprocessor rule if just we unconditionally include
<unistd.h> (on non-Windows systems).
Also, I've added a #warning for to help porters detect when a suitable
implementation isn't detected at compile-time.
Howard: Matthew, can you patch CREDITS.TXT? Thanks.
llvm-svn: 185275
template typename deductions on swap<> (used in string.cpp). Use
decltype(errno) to replicate the type and qualifier information for holding the
errno value. Because errno is expected to be assignable, there is no need to
use typename std::remove_const<decltype(errno)>::type to hold the value.
llvm-svn: 173172
building against libsupc++ as the functions for which they are used are provided
by libsupc++. Simply preprocess them away when building against libsupc++.
llvm-svn: 173165
inlined. These do not need to be always-inlined for ABI stability because they are not exported beyond this source due to the unnamed namespace.
Also simplified use of the Wmissing-field-initializers pragma as was done for clang.
llvm-svn: 171202
functions to protect against duration and time_point overflow. Since
we're about to wait anyway, we can afford to spend a few more cycles on
this checking. I purposefully did not treat the timed try_locks with
overflow checking. This fixes
http://llvm.org/bugs/show_bug.cgi?id=13721 . I'm unsure if the standard
needs clarification in this area, or if this is simply QOI. The
<chrono> facilities were never intended to overflow check, but just to
not overflow if durations stayed within +/- 292 years.
llvm-svn: 162925
__time_get_storage<char> to match the initialization behavior in
__time_get_storage<wchar>. Without the initialization, valgrind
reports errors in the subsequent calls to strftime_l.
llvm-svn: 161196
localization/locale.categories/category.collate/category.ctype/locale.ctype.byname/is_1.pass.cpp
and scan_is.pass.cpp. The tests fail when the character class being
tested is compound, like ctype_base::alnum or ctype_base::graph,
because the existing series of conditionals in do_is an do_scan_is
will abort too early. For instance, if the character class being
tested is alnum, and the character is numeric, do_is will return false
because iswalpha_l will return false, 'result' becomes false, and the
'true' result from the later call to iswdigit_l ends up being ignored
. A similar problem exists in do_scan_is.
llvm-svn: 161192
section in libc++. This requires a recompiled dylib. Failure to rebuild
the dylib will result in a link-time error if and only if the functions from
[util.smartptr.shared.atomic] are used.
The implementation is not lock free. After considerable thought, I know of no
way to make the implementation lock free. Ideas welcome along that front. But
changing the ABI of shared_ptr is not on the table at this point.
The mutex used to lock these function is encapsulated by std::__sp_mut. The
only thing the client knows about std::__sp_mut is that it has a void* data
member, can't be constructed, and has lock and unlock members. Within the
binary __sp_mut is currently implemented as a pointer to a std::mutex. That can
change in the future without disturbing the ABI (as long as sizeof(__sp_mut)
remains constant.
I specifically did not make __sp_mut a spin lock as I have a pathological
distrust of spin locks. Testing on OS X reveals that the use of std::mutex in
this role is not a large performance penalty as long as the contention for the
mutex is low (more likely to get the lock than to have to wait). In the future
we can still make __sp_mut a spin lock if that is what is desired (without ABI
damage).
The dylib contains 16 __sp_mut's to be chosen based on the hash of the address
of the shared_ptr. The constant 16 is a ball-park reasonable space/time
tradeoff.
std::hash<T*> was changed to call __murmur2_or_cityhash, instead of the identity
function. I had thought we had already done this, but I was mistaken.
All of this is under #if __has_feature(cxx_atomic) even though the
implementation is not lock free, because the signatures require access to
std::memory_order, which is currently available only under
__has_feature(cxx_atomic).
llvm-svn: 160940
based on the LIBCXXRT and _LIBCPPABI_VERSION defines, but those files
do not currently include <cxxabi.h> in the non __APPLE__ case. The
attached patch updates those files so that for non __APPLE__ builds
<cxxabi.h> is included if available or if LIBCXXRT is set. I'm
modeling this on the recent updates to exception.cpp.
llvm-svn: 160790
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
Solaris not providing some of the locales that the test suite uses.
Note: This depends on an xlocale (partial) implementation for Solaris and a
couple of fixed standard headers. These will be committed to a branch later
today.
llvm-svn: 151720
libc++ now mostly works on FreeBSD with libcxxrt and this patch applied to the base system:
http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110920/e666632c/xlocale-0001.obj
Summary of tests on FreeBSD:
****************************************************
Results for /root/libcxx/test:
using FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
with -std=c++0x -stdlib=libc++ -I/root/libcxx/include -L/root/libcxx/build/lib
----------------------------------------------------
sections without tests : 1
sections with failures : 48
sections without failures: 1015
+ ----
total number of sections : 1064
----------------------------------------------------
number of tests failed : 145
number of tests passed : 4179
+ ----
total number of tests : 4324
****************************************************
(Many due to this clang version not supporting C++ atomics)
More fixes to follow...
llvm-svn: 140245
all platforms. Unfortunately a lot of this remains conditionally
compiled so as not to break Apple's ABI.
The new _LIBCPP_LOCALE__L_EXTENSIONS macro can be defined on other
platforms that support _l suffixes for all functions in order to use
them.
llvm-svn: 135035
traits.
To the best of my knowledge, this will not break the ABI for Apple.
However, it does introduce three publicly visible (although with
reserved name) functions that will fail to link against the just-shipped
Apple version of libc++. Since they are not used in any inline
functions, no actual breakage should occur.
If Howard doesn't want to put undefined functions (even internal ones)
into a header, they could be surrounded by additional conditional
compilation.
llvm-svn: 134781
David Majnemer