Currently libc++ compiles a special version of error_category()
into the dylib. This definition is no longer needed, and doesn't
work on Windows due to dllimport/dllexport semantics.
For those reasons this patch introduces an option to
disable/enable this definition. By default the definition
is provided in ABI v1 except on windows. This patch
also addresses D28210.
llvm-svn: 290840
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290839
The locale structures have been made opaque in CRT 14+. This currently
prevents building libc++ for Windows. We can re-enable this in the
future when we have replicated the structure to access the private field
for the name (unless there exists a better supported mechanism to query
the name of a locale given the locale_t).
llvm-svn: 290835
As pointed out by Howard, this is actually 134774 days (* 24 * 3600),
and therefore seconds, not 100ns units. Adjust the units to reflect
reality.
llvm-svn: 290824
Visual C++ 14 and newer split msvcrt into msvcrt and ucrt with flavours
of the ucrt for different environments. This changed the access to the
ctype table by introducing the `__pctype_func` and `__pwctype_func`
accessors. Use this rather than directly accessing `_ctype` which
allows us to be safer in threaded situations by going through the libc
locking.
llvm-svn: 290823
Drawing some inspiration from code from Bill O'Neal as pointed out by
Howard, rework the code to avoid an overflow in the duration. Adjust
the style to match libc++ style as well.
Create a local typedef for the FILETIME duration (100-ns units). Use
this to define the difference between the NT and the UNIX epochs (which
previously overflowed due to the representation limits due to the
bouncing to ns). Return the FILETIME duration biased by the NT-to-UNIX
epoch conversion.
Use of the custom duration makes it easier to read and reason about the
code.
llvm-svn: 290806
system_clock::now is not entirely straight forward on Windows, which
does not have a clock_gettime function.
GetSystemTimeAsFileTime gives us the value relative to the NT epoch (Jan
1 1601) rather than the Unix epoch (Jan 1 1970). However, this function
has a low resolution (~10ms). Newer versions of Windows provide
GetSystemTimePreciseAsFileTime which gives us a much more accurate time
(<1us). Unfortunately, the latter is only available on Windows 8+ when
targeting desktop apps.
llvm-svn: 290803
When building libc++ without threading, strerror_r is not used. Define
the code only when threading is enabled. This allows us to build
system_error for Windows, which ATM doesn't build with threading.
llvm-svn: 290791
This patch implements changes to allow _LIBCPP_ASSERT to throw on failure
instead of aborting. The main changes needed to do this are:
1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer
instead of calling abort directly. Additionally this patch implements two
handler functions, one which aborts and another that throws an exception.
2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which
contain _LIBCPP_ASSERT. This is required in order to prevent assertion
failures throwing through a noexcept function. This macro has no effect
unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined.
Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of
debug mode. Currently we can only have one test case per file, since the test
case will cause the program to abort. Testing debug mode this way would require
thousands of test files, most of which would be 95% boiler plate. I don't think
this is a feasible strategy. Fortunately using a throwing debug handler solves
these issues.
Additionally this patch rewrites the documentation for debug mode.
llvm-svn: 290651
Summary:
The underlying C locales provide the `thousands_sep` and `decimal_point` as strings, possible with more than one character. We currently don't handle this case even for `wchar_t`.
This patch properly converts the mbs -> wide character for `moneypunct_byname<wchar_t>`. For the `moneypunct_byname<char>` case we attempt to narrow the WC and if that fails we also attempt to translate it to some reasonable value. For example we translate U00A0 (non-breaking space) into U0020 (regular space). If none of these conversions succeed then we simply allow the base class to provide a fallback value.
Reviewers: mclow.lists, EricWF
Subscribers: vangyzen, george.burgess.iv, cfe-commits
Differential Revision: https://reviews.llvm.org/D24218
llvm-svn: 289347
The function definitions being guarded by the pragma were all static, so
they wouldn't be exported anyway. In any case, we should prefer the
visibility macros. No functional change.
Differential Revision: https://reviews.llvm.org/D26940
llvm-svn: 287768
The code cannot currently link when using libsupc++ with the
LIBCXX_ENABLE_STATIC_ABI_LIBRARY option.
This change ifdef's out the the destructor and 'what' function for
bad_array_length and bad_array_new_length when GLIBCXX is defined.
The constructors that are left in are the only functions not being provided by
libsupc++ itself, and follows the same pattern that was used to ifdef bad_alloc.
Testing was done on a Linux x86_64 host using GCC 5.4 and libc++ from ToT.
I see no change to the test results when using libsup++ or libstdc++ without
LIBCXX_ENABLE_STATIC_ABI_LIBRARY. When using libsupc++ with
LIBCXX_ENABLE_STATIC_ABI_LIBRARY it will now build and test results are the
same as those without the option specified.
Reviewed as https://reviews.llvm.org/D26186
llvm-svn: 287388
This is a generalization of `_LIBCPP_NEW_DELETE_VIS`; the new macro name
captures the semantics better, and also allows us to get rid of the
`_WIN32` check in `include/new`. No functional change.
Differential Revision: https://reviews.llvm.org/D26702
llvm-svn: 287164
This patch fixes a performance bug when constructing or appending to a path
from a string or c-string. Previously we called 'push_back' to append every
single character. This caused multiple re-allocation and copies when at most
one reallocation is necessary. The new behavior is to simply call
`string::append` so it can correctly handle reallocation.
For large strings this change is a ~4x improvement. This also makes our path
faster to construct than libstdc++'s.
llvm-svn: 285530
This patch entirely rewrites the parsing logic for paths. Unlike the previous
implementation this one stores information about the current state; For example
if we are in a trailing separator or a root separator. This avoids the need for
extra lookahead (and extra work) when incrementing or decrementing an iterator.
Roughly this gives us a 15% speedup over the previous implementation.
Unfortunately this implementation is still a lot slower than libstdc++'s.
Because libstdc++ pre-parses and splits the path upon construction their
iterators are trivial to increment/decrement. This makes libc++ lazy parsing
100x slower than libstdc++. However the pre-parsing libstdc++ causes a ton
of extra and unneeded allocations when constructing the string. For example
`path("/foo/bar/")` would require at least 5 allocations with libstdc++
whereas libc++ uses only one. The non-allocating behavior is much preferable
when you consider filesystem usages like 'exists("/foo/bar/")'.
Even then libc++'s path seems to be twice as slow to simply construct compared
to libstdc++. More investigation is needed about this.
llvm-svn: 285526
This patch does two seperate things. First it adds a file called
"__libcpp_version" which only contains the current libc++ version
(currently 4000). This file is not intended for use as a header. This file
is used by Clang in order to easily determine the installed libc++ version.
This allows Clang to enable/disable certain language features only when the
library supports them.
The second change is the addition of _LIBCPP_LIBRARY_VERSION macro, which
returns the version of the installed dylib since it may be different than
the headers.
llvm-svn: 285382
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
Convert the Solaris xlocale.c compatibility library from plain C to C++
in order to fix the build failures caused by the addition of -std=c++11
to LIBCXX_COMPILE_FLAGS. The additional flag got propagated to the C
file, resulting in error with strict compilers.
Differential Revision: https://reviews.llvm.org/D25431
llvm-svn: 284494
Fix the iswxdigit_l() function prototype to take wint_t parameter
instead of incorrect wchar_t.
Differential Revision: https://reviews.llvm.org/D25431
llvm-svn: 284493
Summary:
This patch implements the library side of P0035R4. The implementation is thanks to @rsmith.
In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects.
Reviewers: mclow.lists, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D25591
llvm-svn: 284206
These functions were removed from the dylib sometime between the 3.9 release
and now. This patch manually exports them to re-gain ABI compatibility.
llvm-svn: 284193
Summary:
Adapt implementation of Library Fundamentals TS optional into an implementation of N4606 optional.
- Update relational operators per http://wg21.link/P0307
- Update to requirements of http://wg21.link/P0032
- Extension: Implement trivial copy/move construction/assignment for `optional<T>` when `T` is trivially copyable.
Audit P/Rs for optional LWG issues:
- 2756 "C++ WP optional<T> should 'forward' T's implicit conversions" Implemented, which also resolves 2753 "Optional's constructors and assignments need constraints" (modulo my refusal to explicitly delete the move operations, which is a design error that I'm working on correcting in the 2756 P/R).
- 2736 "nullopt_t insufficiently constrained" Already conforming. I've added a test ensuring that `nullopt_t` is not copy-initializable from an empty braced-init-list, which I believe is the root intent of the issue, to avoid regression.
- 2740 "constexpr optional<T>::operator->" Already conforming.
- 2746 "Inconsistency between requirements for emplace between optional and variant" No P/R, but note that the author's '"suggested resolution" is already implemented.
- 2748 "swappable traits for optionals" Already conforming.
- 2753 "Optional's constructors and assignments need constraints" Implemented.
Most of the work for this patch was done by Casey Carter @ Microsoft. Thank you Casey!
Reviewers: mclow.lists, CaseyCarter, EricWF
Differential Revision: https://reviews.llvm.org/D22741
llvm-svn: 283980
This patch is largely thanks to Casey Carter @ Microsoft. He did the initial
work of porting our experimental implementation and tests over to namespace
std.
llvm-svn: 283977
Fuchsia is a new operating system which uses musl as the standard
C library, libc++ and libc++abi as the C++ standard library.
Differential Revision: https://reviews.llvm.org/D25414
llvm-svn: 283788
This patch applies the _LIBCPP_SAFE_STATIC attribute to internal globals,
most of which are locking primitives, in order to ensure that they can
safely be used during program startup.
This patch also fixes an unsafe static init issue with the global locks
used to implement atomic operations on shared pointers. Previously the
locks were initialized using a dynamically initialized pointer, so it was
possible that the pointer was uninitialized.
llvm-svn: 282640
The ::stat struct on Linux, FreeBSD, and OS X provides the access and
modification times as an instance of 'timespec', which has a nanosecond
resolution. The 'st_mtime' and 'st_atime' members simply reference the 'tv_sec'
value of the timespec struct. This patch changes 'last_write_time(...)' so that
it extracts both the seconds and nanoseconds values of the last modification
time, providing a more accurate implementation of 'last_write_time(...)'.
Additionally this patch fixes a possible signed integer overflow bug. The
'file_time_type' type cannot represent all possible values returned by
the filesystem. Attempting to construct a 'file_time_type' from one of these
values is undefined behavior. This patch avoids that UB by detecting possible
overflows before the conversion.
llvm-svn: 282634
Summary:
This patch has been a long time coming (Thanks @eugenis). It changes `_LIBCPP_INLINE_VISIBILITY` to use `__attribute__((internal_linkage))` instead of `__attribute__((visibility("hidden"), always_inline))`.
The point of `_LIBCPP_INLINE_VISIBILITY` is to prevent inline functions from being exported from both the libc++ library and from user libraries. This helps libc++ better manage it's ABI.
Previously this was done by forcing inlining and modifying the symbols visibility. However inlining isn't guaranteed and symbol visibility only affects shared libraries making this an imperfect solution. `internal_linkage` improves this situation by making all symbols local to the TU they are emitted in, regardless of inlining or visibility. IIRC the effect of applying `__attribute__((internal_linkage))` to an inline function is the same as applying `static`.
For more information about the attribute see: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
Most of the work for this patch was done by @eugenis.
Reviewers: mclow.lists, eugenis
Subscribers: eugenis, cfe-commits
Differential Revision: https://reviews.llvm.org/D24642
llvm-svn: 282345
On Windows, marking an `extern template class` declaration as exported
actually forces an instantiation, which is not the desired behavior.
Instead, the actual explicit instantiations need to be exported.
Differential Revision: https://reviews.llvm.org/D24679
llvm-svn: 281925
Summary:
None of these checks are specific to Android devices. If libc++ was
used with Bionic on a normal Linux system these checks would still be
needed.
Reviewers: mclow.lists, EricWF
Subscribers: compnerd, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D24690
llvm-svn: 281921
When `_LIBCPP_NO_EXCEPTIONS` is defined, we end up with compile errors
when targeting MSVCRT:
* Code includes `<new>`
* `<new>` includes `<cstdlib>` in order to get `abort`
* `<cstdlib>` includes `<stdlib.h>`, _before_ the `using ::abort`
* `<stdlib.h>` includes `locale_win32.h`
* `locale_win32.h` includes `<memory>`
* `<memory>` includes `<stdexcept>`
* `<stdexcept>` includes `<cstdlib` for `abort`, but that inclusion gets
(correctly) ignored because of header guards
* `<stdexcept>` references `_VSTD::abort`, which isn't declared
The easiest solution is to make `locale_win32.h` not include `<memory>`,
by removing the use of `unique_ptr` and manually restoring the locale
instead.
Differential Revision: https://reviews.llvm.org/D24374
llvm-svn: 281641
call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load has to be an acquire atomic load.
Differential Revision: https://reviews.llvm.org/D24028
llvm-svn: 280621
Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.
Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:
>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.
However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".
Reviewers: mclow.lists, bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24159
llvm-svn: 280588
Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:
* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D24003
llvm-svn: 280007
If the last destruction is uncontended, skip the atomic store on
__shared_weak_owners_. This shifts some costs from normal
shared_ptr usage to weak_ptr uses.
https://reviews.llvm.org/D22470
llvm-svn: 277357
The end pointer should point to one past the end of the newly allocated
buffer.
rdar://problem/24265174
Differential Revision: http://reviews.llvm.org/D20334
llvm-svn: 274132
This patch makes the bind placeholders in std::placeholders both (1) const and
(2) constexpr (See below).
This is technically a breaking change for any code using the placeholders
outside of std::bind and depending on them being non-const. However I don't
think this will break any real world code.
(1) Previously the placeholders were non-const extern globals in all
dialects. This patch changes these extern globals to be const in all dialects.
Since the cv-qualifiers don't participate in name mangling for globals this
is an ABI compatible change.
(2) Make the placeholders constexpr in C++11 and beyond. Although LWG 2488 only
applies to C++17 I don't see any reason not to backport this change.
llvm-svn: 273824
This changes how filesystem::permissions(p, perms) handles symlinks. Previously
symlinks were not resolved by default instead only getting resolved when
"perms::resolve_symlinks" was used. After this change symlinks are resolved
by default and perms::symlink_nofollow must be given to change this.
This issue has not yet been moved to Ready status, and I will revert if it
doesn't get moved at the current meeting. However I feel confident that it
will and it's nice to have implementations when moving issues.
llvm-svn: 273328
* Fix non-null violation in strstream.cpp
Overflow was calling memcpy with a null parameter and a size of 0.
* Fix std/atomics/atomics.flag/ tests:
a.test_and_set() was reading from an uninitialized atomic, but wasn't
using the value. The tests now clear the flag before performing the
first test_and_set. This allows UBSAN to test that clear doesn't read
an invalid value.
* Fix std/experimental/algorithms/alg.random.sample/sample.pass.cpp
The tests were dereferencing a past-the-end pointer to an array so that
they could do pointer arithmetic with it. Instead of dereference the iterator
I changed the tests to use the special 'base()' test iterator method.
* Add -fno-sanitize=float-divide-by-zero to suppress division by zero UBSAN diagnostics.
The tests that cause float division by zero are explicitly aware that they
are doing that. Since this is well defined for IEEE floats suppress the warnings
for now.
llvm-svn: 273107
* Fix passing a negative number as either tv_usec or tv_nsec. When file_time_type
is negative and has a non-zero sub-second value we subtract 1 from tv_sec
and make the sub-second duration positive.
* Detect and report when 'file_time_type' cannot be represented by time_t. This
happens when using large/small file_time_type values with a 32 bit time_t.
There is more work to be done in the implementation. It should start to use
stat's st_mtim or st_mtimeval if it's provided as an extension. That way
we can provide a better resolution.
llvm-svn: 273103
Summary:
Currently the implementation of [util.smartptr.shared.atomic] is provided only when using Clang, and not with GCC. This is a relic of not having a GCC implementation of <atomic>, even though <atomic> isn't actually used in the implementation. This patch enables support for atomic shared_ptr functions when using GCC.
Note that this is not a header only change. Previously only Clang builds of libc++.so would provide the required symbols. There is no reason for this restriction.
After this change both Clang and GCC builds should be binary compatible with each other WRT these symbols.
Reviewers: mclow.lists, rmaprath, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21407
llvm-svn: 273076
Currently 4 tests are failing on the ARM buildbot. To try and diagnose each
of the failures this patch does the following:
1) path.itr/iterator.pass.cpp
* Temporarily print iteration sequence to see where its failing.
2) path.native.obs/string_alloc.pass.cpp
* Remove test that ::new is not called when constructing a short string
that requires a conversion. Since during the conversion global locale
objects might be constructed.
3) fs.op.funcs/space.pass.cpp
* Explicitly use uintmax_t in the implementation of space, hopefully
preventing possible overflows.
* Add additional tests that check for overflow is the calculation of the
space_info values.
* Add additional tests for the values returned from statfvs.
4) fs.op.funcs/last_write_time.pass.cpp
* No changes made yet.
llvm-svn: 273075
r273060 didn't completely fix the issues in recursive_directory_iterator and
the tests. This patch follows up with more fixes
* Fix bug where recursive_directory_iterator::increment(ec) did not reset
the error code if no failure occurred.
* Fix bad assertion in the recursive_directory_iterator::increment(ec) test
that would only fire for certain iteration orders.
llvm-svn: 273070
There are two fixes in this patch:
* Fix bug where the constructor of recursive_directory_iterator did not reset
the error code if no failure occurred.
* Fix tests were dependent on the iteration order of the test directories.
llvm-svn: 273060
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
llvm-svn: 273034
CloudABI has gained the mblen_l() function in the meantime that does
properly return whether the character set has shift-states (read:
never).
llvm-svn: 272886
Summary:
Android didn't gain GNU's strerror_r until Marshmallow. If we're
building libc++ against something older (we build the NDK library
against the oldest release we support, currently Gingerbread), fall
back to the POSIX version.
Reviewers: mclow.lists, EricWF
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D21402
llvm-svn: 272827
Summary:
system_error::message() uses `strerror` for the generic and system categories. This function is not thread safe.
The fix is to use `strerror_r`. It has been available since 2001 for GNU libc and since BSD 4.4 on FreeBSD/OS X.
On platforms with GNU libc the extended version is used which always returns a valid string, even if an error occurs.
In single-threaded builds `strerror` is still used.
See https://llvm.org/bugs/show_bug.cgi?id=25598
Reviewers: majnemer, mclow.lists
Subscribers: erik65536, cfe-commits, emaste
Differential Revision: http://reviews.llvm.org/D20903
llvm-svn: 272633
Some pthread implementations do not like being called pthead_join()
with the pthread_t argument set to 0, and causes a segfault. This
patch fixes this issue by validating the pthread_t argument before
invoking pthread_join().
NFC.
Differential revision: http://reviews.llvm.org/D20929
Change-Id: Ief817c57bd0e1f43cbaa03061e02417d6a180c38
Reviewers: EricWF
llvm-svn: 271634
This patch extracts out all the pthread dependencies of libcxx into the
new header __threading_support. The motivation is to make it easy to
re-target libcxx into platforms that do not support pthread.
Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781
Applied with tweaks - D19412
Change-Id: I301111f0075de93dd8129416e06babc195aa936b
llvm-svn: 268734
Summary:
Out-of-line symbols for <experimental/...> headers are not ABI or API stable and cannot live in the 'libc++.dylib'. Currently they have nowhere to live. I would like to add a new library target `libc++experimental.a` to fix this.
Previously I had suggested different libraries for different TS's (`libc++filesystem.a`, 'libc++LFTS.a`, ect). I no longer think this is the right approach.
Instead `c++experimental` will hold *all* TS implementations as a single monolithic library. I see two main benefits to this:
1. Users only have to know about and manually link one library.
2. It makes it easy to implement TS's with one or two out-of-line symbols. (Ex. PMRs)
`c++experimental` provides NO ABI compatibility. Symbols can freely be added/removed/changed without concern for ABI stability.
I will add documentation for this after landing this patch (but before adding anything to it).
`c++experimental` only builds as a static library. By default CMake will build/test this library but will *NOT* install it.
This patch adds the CMake and LIT logic needed to build/test the new library. Once this lands I plan on using it to implement parts of `<experimental/memory_resource>`.
Reviewers: mclow.lists
Subscribers: cfe-commits, theraven, krememek, dexonsmith, bcraig, beanz, danalbert
Differential Revision: http://reviews.llvm.org/D19856
llvm-svn: 268443
Instead of checking _LIBCPP_LOCALE_L_EXTENSIONS all over, instead check it
once, and define the various *_l symbols once. The private redirector symbol
names are all prefixed with _libcpp_* so that they won't conflict with user
symbols, and so they won't conflict with future C library symbols. In
particular, glibc likes providing private symbols such as __locale_t, so we
should follow a different naming pattern (like _libcpp_*) to avoid problems
on that front.
Tested on Linux with glibc. Hoping for the best on OSX and the various BSDs.
http://reviews.llvm.org/D17456
llvm-svn: 263016
Instead of excluding all known operating systems that are not derived from BSD,
I now include all operating systems that claim to be derived from BSD.
Hopefully, that will make it so that this check doesn't need to change for
every new operating system that comes along.
http://reviews.llvm.org/D16634
llvm-svn: 259193
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
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 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
Summary:
In rL241532, atomic_support.h was added, which provides handling of
atomic operations for libc++. When atomic builtins are not available,
it emits a warning about being unsupported, but it still provides a
number of stubs for the required functions.
However, it misses a stub for `__libcpp_relaxed_store()`. Add it, by
using the same implementation as for `__libcpp_atomic_store()`.
(Note that I encountered this on arm-freebsd, which still defaults to
armv4, and does not have the runtime libcalls to support atomic
builtins. For now, I have simply disabled using them.)
Reviewers: mclow.lists, EricWF
Subscribers: theraven, cfe-commits, jroelofs, majnemer, aemerson
Differential Revision: http://reviews.llvm.org/D13051
llvm-svn: 248313
Summary:
After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initialization is a concern the syntax required to get it is C++11 only. Meaning that C++11 constant static initialization cannot silently break in C++03, it will always cause a syntax error. Furthermore `ATOMIC_VAR_INIT` and `ATOMIC_FLAG_INIT` remain defined in C++03 even though they cannot be used because C++03 usages will cause better error messages.
The main change in this patch is to replace `__has_feature(cxx_atomic)`, which only returns true when C++ >= 11, to `__has_extension(c_atomic)` which returns true whenever clang supports the required atomic builtins.
This patch adds the following macros:
* `_LIBCPP_HAS_C_ATOMIC_IMP` - Defined on clang versions which provide the C `_Atomic` keyword.
* `_LIBCPP_HAS_GCC_ATOMIC_IMP` - Defined on GCC > 4.7. We must use the fallback atomic implementation.
* `_LIBCPP_HAS_NO_ATOMIC_HEADER` - Defined when it is not safe to include `<atomic>`.
`_LIBCPP_HAS_C_ATOMIC_IMP` and `_LIBCPP_HAS_GCC_ATOMIC_IMP` are mutually exclusive, only one should be defined. If neither is defined then `<atomic>` is not implemented and including `<atomic>` will issue an error.
Reviewers: chandlerc, jroelofs, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11555
llvm-svn: 245463
Summary:
In some places in libc++ we need to use the `__atomic_*` builtins. This patch adds a header that provides access to those builtins in a uniform way from within the dylib source.
If the compiler building the dylib does not support these builtins then a warning is issued.
Only relaxed loads are needed within the headers. A singe function to do these relaxed loads has been added to `<memory>`.
This patch applies the new atomic builtins to `__shared_count` and `call_once`.
Reviewers: mclow.lists
Subscribers: majnemer, jroelofs, cfe-commits
Differential Revision: http://reviews.llvm.org/D10406
llvm-svn: 241532
After r241454 landed, libc++'s locale code compiles on CloudABI, with
the exception of the following two bits:
- CloudABI doesn't have setlocale(), as the C library does not keep
track of any global state. The global locale is always set to "C".
Disable the call to setlocale() on this system.
- Similarly, mbtowc_l() is also not present, as it is also not
thread-safe. As CloudABI does not support state-dependent encodings,
simply disable that part of the logic.
The locale code now compiles out of the box on CloudABI.
Differential Revision: http://reviews.llvm.org/D10729
Reviewed by: jroelofs
llvm-svn: 241455
The __cloc() function is only present in case the environment does not
provide a way to refer to the C locale using a compile-time constant
expression. _LIBCPP_GET_C_LOCALE seems to be defined unconditionally.
This improves compilation of the locale code on CloudABI.
Differential Revision: http://reviews.llvm.org/D10690
Reviewed by: jroelofs
llvm-svn: 241454
Within the shared state methods do not unlock the lock guards manually. This
could cause a race condition where the shared state is destroyed before the
method is complete.
llvm-svn: 239577
The changes in src/exception.cpp and cmake/Modules/HandleLibCXXABI.cmake fix a
bug when building libc++ with GCC. Because GCC does not support __has_include
we need to explicitly tell it that we are building against libc++abi via the
preprocessor definition `LIBCXX_BUILDING_LIBCXXABI`.
The changes in include/ratio are to work around CWG defect
1712 (constexpr variable template declarations). GCC 4.8 and before has not
adopted the resolution to this defect.
The changes in include/exception work around an issue where is_final is used
without it being defined in type_traits.
llvm-svn: 237767
The system_clock::now() function currently uses gettimeofday(). The
problem with gettimeofday() is that it is an obsolete XSI function,
hence unavailable on CloudABI. See:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html
Change this code to use clock_gettime() with CLOCK_REALTIME instead,
which is more consistent, as clock_gettime() is already used for
steady_clock.
A previous version of this change actually attempted to change
system_clock::duration, but I reverted this part as it breaks the
existing ABI.
Differential Revision: http://reviews.llvm.org/D8253
Approved by: jroelofs
llvm-svn: 237390
The idea behind Nuxi CloudABI is that it is targeted at (but not limited to)
running networked services in a sandboxed environment. The model behind stdin,
stdout and stderr is strongly focused on interactive tools in a command shell.
CloudABI does not support the notion of stdin and stdout, as 'standard
input/output' does not apply to services. The concept of stderr does makes
sense though, as services do need some mechanism to log error messages in a
uniform way.
This patch extends libc++ in such a way that std::cin and std::cout and the
associated <cstdio>/<cwchar> functions can be disabled through the flags
_LIBCPP_HAS_NO_STDIN and _LIBCPP_HAS_NO_STDOUT, respectively. At the same time
it attempts to clean up src/iostream.cpp a bit. Instead of using a single array
of mbstate_t objects and hardcoding the array indices, it creates separate
objects that declared next to the iostream objects and their buffers. The code
is also restructured by interleaving the construction and setup of c* and wc*
objects. That way it is more obvious that this is done identically.
The c* and wc* objects already have separate unit tests. Make use of this fact
by adding XFAILs in case libcpp-has-no-std* is set. That way the tests work in
both directions. If stdin or stdout is disabled, these tests will therefore
test for the absence of c* and wc*.
Differential Revision: http://reviews.llvm.org/D8340
llvm-svn: 233275
If we want to add support for making std::cin and std::cout optional, it
is impractical to have all of the mbstate_t objects in one array. This
would mean that if std::cin and std::cout are omitted, the state_types
array is only used partially.
Solve this by using separate global variables. These are placed right
next to the iostream object and the buffer, meaning we can easily #ifdef
them away.
Differential Revision: http://reviews.llvm.org/D8359
llvm-svn: 233274
Interleave the code for narrow and wide character streams. This makes it
more obvious that the two pieces of code are identical. Furthermore, it
makes it easier to conditionally compile support for certain streams, as
less #ifdef blocks are needed.
Differential Revision: http://reviews.llvm.org/D8342
Reviewed by: marshall
llvm-svn: 232516
This basically reverts the revert in r216508, and fixes a few more cases while
I'm at it. Reading my commit message on that commit again, I think it's bupkis.
http://reviews.llvm.org/D8237
llvm-svn: 231940
As CloudABI does not provide sysctl(), this header is not present. Make
thread.cpp build correctly (and pass all tests) by not including the header.
llvm-svn: 231768
There are a couple of places where libc++ prints log/error messages to
stdout on its own. This may of course interfere with the output
generated with applications. Log/error messages should be directed to
stderr instead.
Differential Revision: http://reviews.llvm.org/D8135
Reviewed by: marshall
llvm-svn: 231767
Nuxi CloudABI (https://github.com/NuxiNL/cloudlibc) does not allow
processes to access the global filesystem namespace. This breaks
random_device, as it attempts to use /dev/{u,}random. This change adds
support for arc4random(), which is present on CloudABI.
In my opinion it would also make sense to use arc4random() on other
operating systems, such as *BSD and Mac OS X, but I'd rather leave that
to the maintainers of the respective platforms. Switching to
arc4random() does change the ABI.
This change also attempts to make some cleanups to the code. It adds a
single #define for every random interface, instead of testing against
operating systems explicitly.
As discussed, also validate the token argument to be equal to
"/dev/urandom" on all systems that only provide pseudo-random numbers.
This should cause little to no breakage, as "/dev/urandom" is also the
default argument value.
Reviewed by: jfb
Differential Revision: http://reviews.llvm.org/D8134
llvm-svn: 231764
Summary: Newlib supports ctype differently from other platforms, this patch teaches libc++ about yet another platform that does ctype differently.
Reviewers: jroelofs
Subscribers: cfe-commits, danalbert, EricWF, jvoung, jfb, mclow.lists
Differential Revision: http://reviews.llvm.org/D7888
llvm-svn: 230557
Summary:
GCC emits a pretty amusing warning when there are apostrophes in a #warning:
```warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]```
Reword the warning to avoid this, and be more consistent with other warnings in libc++.
Reviewers: danalbert
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7818
llvm-svn: 230298
Summary: NaCl shouldn't include sysctl.h when trying to determine std:🧵:hardware_concurrency, it should instead use sysconf(_SC_NPROCESSORS_ONLN) through unistd.h. No test needs to be changed, since hardware_concurrency.pass.cpp already tests that std:🧵:hardware_concurrency > 0.
Test Plan: make check-libcxx
Reviewers: dschuff, danalbert
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D6470
llvm-svn: 223128
Summary:
The NaCl sandbox doesn't allow opening files under /dev, but it offers an API which provides the same capabilities. This is the same random device emulation that nacl_io performs for POSIX support, but nacl_io is an optional library so libc++ can't assume that device emulation will be performed. Note that NaCl only supports /dev/urandom, not /dev/random.
This patch also cleans up some of the preprocessor #endif, and fixes the test for Win32 (it accepts any token, and would therefore never throw regardless of the token provided).
Test Plan: ninja check-libcxx
Reviewers: dschuff, mclow.lists, danalbert
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D6442
llvm-svn: 223068
Since the initialization of the pointer happens across the libc library boundry
MSAN will not know the pointer was initialized. This fixes MSAN failures in
test/strings/string.conversions.
llvm-svn: 222052
If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.
http://reviews.llvm.org/D3969
llvm-svn: 217271
After discussing implementing more tests for this with @danalbert & @mclow, I
realized this change is not correct.
The C++ standard requires do_is() to behave as if it were a loop that checked
is(). Furthermore, it requires is() to check "The first form returns the result
of the expression (M & m) != 0; i.e., true if the character has the
characteristics specified"... which the reverted patch definitely does not
conform to. Even further, furthermore, this requires that ctype's mask be an
actual bitmask, unlike what android and newlib provide for _ctype_.
Fixing the original bug that instigated this patch remains TBD.
llvm-svn: 216508
Turning off explicit template instantiation leads to a pretty
significant build time and code size cost. We're better off dealing
with ABI incompatibility issues that come up in a less heavy handed
way.
This reverts commit r189610.
llvm-svn: 215740
__get_classname() and __bracket_expression were assuming that
char_class_type was ctype_base::mask rather than using
regex_traits<_CharT>::char_class_type.
This change allows char_class_type to be defined to something other than
ctype_base::mask so that the implementation will still work for
platforms with an 8-bit ctype mask (such as Android and OpenBSD).
llvm-svn: 214201
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
Eric Fiselier