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
When <bitset> is compiled with warnings enabled, on a platform where
size_t is 4 bytes, it results in errors similar to:
bitset:265:16: error: non-constant-expression cannot be narrowed
from type 'unsigned long long' to '__storage_type' (aka 'unsigned
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
^~~
bitset:676:52: note: in instantiation of member function
'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
^
Fix these by casting the initializer list elements to __storage_type.
Reviewers: mclow.lists, EricWF
Differential Revision: https://reviews.llvm.org/D23960
llvm-svn: 280543
Microsoft removed gets from the CRT in Visual Studio 2015 onwards [1].
Attempting to reference it when targeting CRT versions 14 and above will cause
compile errors.
[1] https://msdn.microsoft.com/en-us/library/2029ea5f.aspx
Patch by Shoaib Meenai!
llvm-svn: 280417
`-fPIC` doesn't make much sense for Windows, since Windows DLLs aren't compiled
position independent and are instead relocated at runtime.
Patch by Shoaib Meenai!
llvm-svn: 280413
In r280108 I tried to make the headers copy relative to LLVM_BINARY_DIR, and the intent was that it would only happen on in-tree builds or runtimes directory builds. It didn't actually work that way.
This patch adds a check for CMAKE_SOURCE_DIR being equal to CMAKE_CURRENT_SOURCE_DIR. In this case we set a variable LIBCXX_USING_INSTLLED_LLVM. This doesn't necessarily mean the LLVM is installed (it could be a build directory), but it means we need to treat the LLVM directory as read-only.
llvm-svn: 280400
Summary: This copy phase is only needed for in-tree builds, so we should be copying to the LLVM build directory's include dir instead of the sub-project include dir.
Reviewers: bogner, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24015
llvm-svn: 280108
Some of the mutex tests fail on machines with high load. This patch implements
the test directive "// FLAKY_TEST" which allows a test to be run 3 times
before it's considered a failure.
llvm-svn: 280050
We're compiling libc++ with -nodefaultlibs, so we should also pass this
option during the configuration checks to ensure those checks are
consistent with the actual build.
The primary motivation here is to ease cross-compilation against a
non-standard set of C++ libraries. Previously, the configuration checks
would attempt to link against the standard C++ libraries, which would
cause link failures when cross-compiling, even though the actual library
link would go through correctly (because of the use of -nodefaultlibs
and explicitly specifying any needed libraries). This is more correct
even ignoring the motivation, however.
Patch by Shoaib Meenai!
llvm-svn: 280015
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
This patch enables the `cxx-benchmarks` target by default. Note that the target
still has to be manually invoked since it isn't included in the default 'make'
rule.
This patch also gets the benchmarks building w/ GCC. The build previously
required the '-stdlib=libc++' flag but upstream patches to Google Benchmark
now allow the library to build w/ libc++ and GCC.
These changes should make the benchmarks easier to build and test.
llvm-svn: 279999
This assignment operator was previously broken since the SFINAE always resulted
in substitution failure. This caused assignments to turn into
copy construction + assignment.
This patch was originally committed as r279953 but was reverted due to warnings
in the test-suite. This new patch corrects those warnings.
llvm-svn: 279955
This assignment operator was previously broken since the SFINAE always resulted
in substitution failure. This caused assignments to turn into
copy construction + assignment.
llvm-svn: 279953
This patch implements the std::sample function added to C++17 from LFTS. It
also removes the std::experimental::sample implementation which now forwards
to std::sample.
llvm-svn: 279948
Libc++'s implementation of shuffle and sample already support lvalue and rvalue
RNG's. This patch adds tests for both categories and marks the issue as complete.
This patch also contains drive-by change for std::experimental::sample which
improves the diagnostics produced when the correct iterator categories are
not supplied.
llvm-svn: 279947
Similar to rL242623, move C++ version checks outside of _NOEXCEPT_()
macro invocation argument lists, to avoid "embedding a directive within
macro arguments has undefined behavior" warnings.
Differential Revision: https://reviews.llvm.org/D23961
llvm-svn: 279926
Summary:
The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name.
This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23699
llvm-svn: 279675
We're compiling libc++ with -nodefaultlibs, so we should also pass this option
during the configuration checks to ensure those checks are consistent with the
actual build.
The primary motivation here is to ease cross-compilation against a non-standard
set of C++ libraries. Previously, the configuration checks would attempt to link
against the standard C++ libraries, which would cause link failures when
cross-compiling, even though the actual library link would go through correctly
(because of the use of -nodefaultlibs and explicitly specifying any needed
libraries). This is more correct even ignoring the motivation, however.
Patch by Shoaib Meenai!
llvm-svn: 279584
Some tests uses 'long double' to/from conversions and for some targets
they are provided by compiler runtime (either compiler-rt or libgcc).
However when building libcxx with linunwinder current test configuration
at target_info.py do not include the required libraries, as:
not llvm_unwinder:
"-lc++" "-lm" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s" "-lgcc"
llvm_unwinder
"-lc++" "-lm" "-lpthread" "-lc" "-lunwind" "-ldl"
This causes some tests build issues with missing symbols on aarch64,
for instance, where 'long double' is a binary float with 128-bits with
mostly of internal operations being provided by software routines.
This patch changes how to define the default linker flags with libunwinder by
adding libgcc regardless.
I checked and aarch64 and x86_64 with libcxx and libunwind (with and without
LIBCXXABI_USE_LLVM_UNWINDER).
llvm-svn: 279552
Summary:
The new LLVM runtimes build directory requires some basic conventions across the runtime projects. These changes make libcxx build under the runtimes subdirectory. The general idea of the changes is that the runtimes subdirectory requires some conventions to be consistent across runtime projects.
I expect to have a few more small patches that build on this to tie up check targets and other things useful in development workflows.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXX_BUILT_STANDALONE -> LIBCXX_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23696
llvm-svn: 279151
The expected 'filesystem::path::compare' result states that for different
path only result sign contains the information about passed arguments
(not its integer value). This is due it uses the output of other compare
functions (basic_string_view and char_traits) without further handling and
char_traits uses memcmp for final buffer comparison.
However for GLIBC on AArch64 the code:
int ret = memcmp ("b/a/c", "a/b/c", 1);
Results in '64' where for x86_64 it results in '1'.
This patch fixes the expected 'filesystem::path::compare' by normalizing
all the results before assert comparison.
llvm-svn: 278745
Currently certain tests get killed when compiled with ASAN at -O0 because
they eat all of the systems memory. This doesn't happen at -O1, so enable that
to work around the issue.
llvm-svn: 278722
Although libc++ only requires C++11 to build, there are other
reasons to turn on a newer dialect in the build. For example
IDE's may not highlight any C++14/C++17 in the headers when
configured for C++11. This patch add's a private option for
changing this.
llvm-svn: 278638
Some filesystems track atime always. This relaxes the test to accept either a
filesystem which does not accurately track atime or does track the atime
accurately. This allows the test to pass on filesystems mounted with
`strictatime` on Linux or on macOS.
llvm-svn: 278357
basic_string's constructor calls init which was not getting inlined. This
prevented optimization of const string as init would appear as a call in between
a string's def and use.
Patch by Laxman Sole and Aditya Kumar.
Differential Revision: https://reviews.llvm.org/D22782
llvm-svn: 278356
I've put some work into the Google Benchmark library in order to make it easier
to benchmark libc++. These changes have already been upstreamed into
Google Benchmark and this patch applies the changes to the in-tree version.
The main improvement in the addition of a 'compare_bench.py' script which
makes it very easy to compare benchmarks. For example to compare the native
STL to libc++ you would run:
`$ compare_bench.py ./util_smartptr.native.out ./util_smartptr.libcxx.out`
And the output would look like:
RUNNING: ./util_smartptr.native.out
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_SharedPtrCreateDestroy 62 ns 62 ns 10937500
BM_SharedPtrIncDecRef 31 ns 31 ns 23972603
BM_WeakPtrIncDecRef 28 ns 28 ns 23648649
RUNNING: ./util_smartptr.libcxx.out
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_SharedPtrCreateDestroy 46 ns 46 ns 14957265
BM_SharedPtrIncDecRef 31 ns 31 ns 22435897
BM_WeakPtrIncDecRef 34 ns 34 ns 21084337
Comparing ./util_smartptr.native.out to ./util_smartptr.libcxx.out
Benchmark Time CPU
-----------------------------------------------------
BM_SharedPtrCreateDestroy -0.26 -0.26
BM_SharedPtrIncDecRef +0.00 +0.00
BM_WeakPtrIncDecRef +0.21 +0.21
llvm-svn: 278147
Neither of these results files has been update in years. Linux now has a dozen
or so buildbots tracking it and the Windows results are no longer relevant.
I plan on looking into getting a Windows buildbot going using Appveyor in the
coming days.
llvm-svn: 278087
This change allows building both shared and static version of libc++
in a single build, sharing object files between both versions.
Differential Revision: https://reviews.llvm.org/D23232
llvm-svn: 278068
Summary:
The synopsis in C++11 subclause 28.8 [re.regex] has:
```
basic_regex(const charT* p, size_t len,
flag_type f = regex_constants::ECMAScript);
```
The default argument is added to libc++ by this change.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22702
Reapplies r277966.
Patch by Jason Liu!
llvm-svn: 277968
Summary:
In the synopsis in C++11 subclause 28.8 [re.regex], `basic_regex` is
specified to have member typedefs `traits_type` and `string_type`. This
change adds them to libc++.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22698
Patch by Jason Liu!
llvm-svn: 277526
It currently fails because GCC changed the mangling of templates, which affects std::atomic using __attribute__((vector(X))). The bot using GCC 4.9 generates the following message:
In file included from /home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:24:0:
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic: In instantiation of 'atomic_test<T>::atomic_test() [with T = __vector(2) int]':
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:66:3: required from here
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: error: 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' conflicts with a previous declaration
__gcc_atomic_t() _NOEXCEPT = default;
^
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: previous declaration 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(1) int]'
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: -fabi-version=6 (or =0) avoids this error with a change in mangling
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: error: 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' conflicts with a previous declaration
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: previous declaration 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(1) int]'
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: -fabi-version=6 (or =0) avoids this error with a change in mangling
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:939:5: note: synthesized method 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' first required here
__atomic_base() _NOEXCEPT = default;
^
GCC's docs say the following about ABI version 6:
Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of C++11 scoped enums and the mangling of template argument packs, const/static_cast, prefix ++ and –, and a class scope function used as a template argument.
llvm-svn: 277380
Summary:
libc++ implements std::atomic<_Tp> using __atomic_base<_Tp> with
`mutable _Atomic(_Tp) __a_`. That member must be suitably aligned on
relevant ISAs for instructions such as cmpxchg to work properly, but
this alignment isn't checked anywhere. __atomic_base's implementation
relies on _Atomic doing "the right thing" since it's under the
compiler's control, and only the compiler knows about lock-freedom and
instruction generation. This test makes sure that the compiler isn't
breaking libc++'s expectations.
I'm looking at a few odd things in the C++ standard, and will have a few
other fixes around this area in the future.
This requires building with `-DLIBCXX_HAS_ATOMIC_LIB=True`, the test
marks the dependency as REQUIRES and won't be run without.
Reviewers: cfe-commits
Subscribers: EricWF, mclow.lists
Differential Revision: http://reviews.llvm.org/D22073
llvm-svn: 277368
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
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
In C++03 mode evaluating the SFINAE can cause a hard error due to
access control violations. This is a problem because the SFINAE
is evaluated as soon as the class is instantiated, and not later.
llvm-svn: 276594
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
There is a bug in Clang 3.6 and earlier that causes compile failures.
I suspect it's due to the usage of member function parameter names in the
attributes.
llvm-svn: 276507
Summary:
This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.
In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message.
Reviewers: mclow.lists, rsmith, jfb, EricWF
Subscribers: bcraig, jfb, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22557
llvm-svn: 276506
Increasingly the .fail.cpp tests are written using -verify, making them
sensitive to the exact diagnostics generated by the compiler. To prevent
additional diagnostics from being generated, and causing the tests to fail,
this patch removes the warning flags when compiling those tests.
llvm-svn: 276208
Although inheriting constructors have already been fixed in Clang 3.9 I still
choose to fix std::function so users can derive from it with older compilers.
llvm-svn: 276090
The previous implementation relied highly on specializations to handle
special cases. This new implementation lets the compiler do the work when possible.
llvm-svn: 276084
Libc++ provides static assertions to detect reference binding issues inside
tuple. This patch adds tests for those diagnostics.
It should be noted that these static assertions technically violate the
standard since it allows these illegal bindings to occur.
Also see https://llvm.org/bugs/show_bug.cgi?id=20855
llvm-svn: 276078
The functions arg, conj, imag, norm, proj, and real have additional overloads
for arguments of integral or floating point types. However these overloads should
not allow conversions to the integral/floating point types, only exact matches.
This patch constrains these functions so they no longer allow conversions.
llvm-svn: 276067
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
Summary:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.
* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.
Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.
To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.
The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`. Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.
To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.
Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.
The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.
Please let me know what you think.
Reviewers: howard.hinnant, mclow.lists
Subscribers: howard.hinnant, bbannier, cfe-commits
Differential Revision: https://reviews.llvm.org/D20786
llvm-svn: 276003
Constructing a std::locale object from an empty string selects the language
from the current environment variables. If the environment variables name
a locale that doesn't exist, or isn't installed, then the construction of
facets using that locale may throw.
This patch removes tests that use 'std::locale l("")'.
The optimal solution would be to manually set the environment variables
in the test. Unfortunately there is no portable way to do this.
llvm-svn: 275772
man page for mkdir says: "If the parent directory has the set-group-ID bit set,
then so will the newly created directory."
Differential Revision: https://reviews.llvm.org/D22265
llvm-svn: 275760
This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.
Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
test suite.
llvm-svn: 275759
Eric Fiselier