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
libc++ currently relies on undefined initialization order of global
initializers when using gcc:
1. __start_std_streams in iostream.cpp calls locale:🆔:_init, which assigns
an id to each locale::facet in an initializer
2. Every facet has a static locale::id id, whose constructor sets the facet's
id to 0
If 2 runs after 1, it clobbers the facet's assigned consecutive id, causing
exceptions to be thrown when e.g. running code like "cout << endl".
To fix this, let _LIBCPP_CONSTEXPR evaluate to "constexpr" instead of nothing
with gcc. locale::id's constructor is marked _LIBCPP_CONSTEXPR, which ensures
that it won't get an initializer that could potentially run after the
iostream.cpp initializer. (This remains broken when building with msvc.)
Also switch constexpr-specific code in bitset to use __SIZEOF_SIZE_T__ instead
of __SIZE_WIDTH__, because gcc doesn't define the latter.
Pair-programmed/debugged with Dana Jansens.
llvm-svn: 210188
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
Other tests in this directory use this type, so it's probably copypasta from
there.
(test_buf only forwards to the superclass in all tests where it's used though,
so I wonder if it can be replaced with just using filebuf / wfilebuf
everywhere?)
llvm-svn: 210019
(clang doesn't complain about this, but gcc does. This is necessary for a
follow-up patch that will enable _LIBCPP_CONSTEXPR for gcc.)
llvm-svn: 209888
[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
r207606 changed the __need_foo macros to behave like they do with gcc: If they
are set, _only_ the __need_foo stuff gets defined. As a consequence, cstddef
no longer defined "offsetof". It looks like the __need_foo defines aren't
needed anymore, so just remove them.
Fixes PR19723.
llvm-svn: 208942
When testing against the system library, there is a relatively minor
ABI breakage that the std::future_errc values have been changed to
avoid using zero. Update the tests that rely on the values being
consistent.
llvm-svn: 208840
These tests haven't been failing on darwin11 or 12 since r189610 when
pr17027 was fixed, but they've been keeping the libc++ bot red by
XPASSing since then.
llvm-svn: 208831
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
libc++ will not call address_sanitizer to detect addressing errors in the
standard library containers. This is a negative macro to enable users to
disable the libc++ checks even if they are compiling with address sanitizer
enabled by defining this macro.
At the present time, there is no code in libc++ that looks at this macro.
That will come soon. This is just infrastructure.
llvm-svn: 206184
It's identical to name() these days. (At one point it avoided masking
of the RTTI uniqueness bit because ARM64 ignored it architecturally,
but no longer).
llvm-svn: 205518
ARM64 generates RTTI with hidden visibility, which means that typeinfo
must be compared char-by-char since it's not guaranteed to be uniqued
across the whole program.
llvm-svn: 205139
to remove redundant wording, which required no changes to libc++. 2075 was a
rewrite of the requirements for forward progress, and again, requires no changes
to the library.
llvm-svn: 204724
Also mark #2104 as complete. Leave the implementation in libc++ as noexcept, since
implementations are allowed to add noexcept to non-virtual calls. If we throw from
unique_lock& operator=(unique_lock&& u), then that means the preconditions were violated,
and calling terminate() (as a result of throwing from a noexcept function) is as
good example of undefined behavior as any other.
llvm-svn: 204653
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
My fix for PR15820 in r180132 inadvertently removed the exclusion for ".*".
This puts it back again. Thanks for Nico Weber for pointing this out!
llvm-svn: 203807
This is unnecessary now that the flag handling has been fixed. The flags will
be added properly in the main CMakeLists.txt after the config-ix inclusion which
performs the required check.
llvm-svn: 203639
Always use list(APPEND) as it will perform the desired action even if the list
is empty or previously unset. The first set is harmless, however, the
subsequent set was overwriting the previous flag setup resulting in an improper
compilation command being generated. This manifested as a build failure on
Linux when using cmake + ninja.
llvm-svn: 203638
add_definitions is meant for adding C preprocessor definitions. Modern cmake
suggests use of the CMAKE_CXX_FLAGS for the purposes of pushing flags to the
compilation commands. Simply switch to the modern form given that we are
already requiring a new enough cmake.
llvm-svn: 203637
Instead, define explicit specializations for the basic types listed in
the SGI documentation. This solves two problems:
1) Helps avoid silent ODR violations caused by the absence of a
user-supplied __gnu_cxx::hash specialization in cases where a std::hash
specialization exists (e.g. for std::string).
2) __gnu_cxx::hash semantics are slightly different to those of
std::hash (for example, the former may dereference a pointer argument)
so it is inappropriate for __gnu_cxx::hash to receive std::hash
specializations by default.
Differential Revision: http://llvm-reviews.chandlerc.com/D2747
llvm-svn: 203070
Marshall Clow