Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331379
When using an old version of glibc, a ::isinf(double) and ::isnan(double)
function is provided, rather than just the macro required by C and C++.
Displace this function using _LIBCPP_PREFERRED_OVERLOAD where possible.
The only remaining case where we should get the wrong return type is now
glibc + libc++ + a non-clang compiler.
llvm-svn: 331241
Be defensive against a reentrant std::function::operator=(nullptr_t), in case
the held function object has a non-trivial destructor. Destroying the function
object in-place can lead to the destructor being called twice.
Patch by Duncan P. N. Exon Smith. C++03 support by Volodymyr Sapsai.
rdar://problem/32836603
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D34331
llvm-svn: 330885
There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
narrowing conversion SFINAE test (see GCC PR63723).
llvm-svn: 330655
Summary:
The patch includes all declarations, and also implements the following features:
* ABI.
* narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast.
Reviewers: mclow.lists, EricWF
Subscribers: lichray, sanjoy, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D41148
llvm-svn: 330627
Summary:
It is immediately preceded by this check:
#if _MSC_VER < 1900
#error "MSVC versions prior to Visual Studio 2015 are not supported"
#endif
Reviewers: EricWF
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D45829
llvm-svn: 330360
The strto* family was introduced in android O (API Level 26). However,
the support headers were adjusted to indicate that all locale aware
functions were added in L. Provide stubs for the locale aware strto*
family until O.
llvm-svn: 330045
This avoids the need for a custom generated config file which is desired
because the custom config files differs per-target which means we cannot
reuse headers across different targets.
Differential Revision: https://reviews.llvm.org/D45304
llvm-svn: 329770
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 329544
this patch adds the <compare> header and implements all of it
except for [comp.alg].
As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.
llvm-svn: 329460
This patch does some housekeeping for the new <version> header.
It adds it to the module.modulemap, and the double_include.sh.cpp test.
Additionally it corrects the // UNSUPPORTED options for the libc++
specific test. The header needs to compile under C++03 to support
modules, and it should compile under all available compilers.
llvm-svn: 329144
This patch implements P0430R2, who's largest change is adding the path::format
enumeration for supporting path format conversions in path constructors.
However, since libc++'s filesystem only really supports POSIX like systems,
there are no real changes needed. This patch simply adds the format enum
and then ignores it when it's passed to constructors.
llvm-svn: 329031
This is a fairly large patch that implements all of the filesystem NB comments
and the relative paths changes (ex. adding weakly_canonical). These issues
and papers are all interrelated so their implementation couldn't be split up
nicely.
This patch upgrades <experimental/filesystem> to match the C++17 spec and not
the published experimental TS spec. Some of the changes in this patch are both
API and ABI breaking, however libc++ makes no guarantee about stability for
experimental implementations.
The major changes in this patch are:
* Implement NB comments for filesystem (P0492R2), including:
* Implement `perm_options` enum as part of NB comments, and update the
`permissions` function to match.
* Implement changes to `remove_filename` and `replace_filename`
* Implement changes to `path::stem()` and `path::extension()` which support
splitting examples like `.profile`.
* Change path iteration to return an empty path instead of '.' for trailing
separators.
* Change `operator/=` to handle absolute paths on the RHS.
* Change `absolute` to no longer accept a current path argument.
* Implement relative paths according to NB comments (P0219r1)
* Combine `path.cpp` and `operations.cpp` since some path functions require
access to the operations internals, and some fs operations require access
to the path parser.
llvm-svn: 329028
This patch corrects num_get for unsigned types to support strings
with a leading `-` character. According to the standard the
number should be parsed as an unsigned integer and then
negated.
llvm-svn: 328751
The NB comments for filesystem changed permissions and added
a new enum `perm_options` which control how the permissions
are applied.
This implements than NB resolution
llvm-svn: 328476
This partially reverts commit r328261. The GCC bug has been fixed in
trunk and has never existed in a released version. Therefore the changes
to variant are unneeded.
However, the additional tests have been left in place.
llvm-svn: 328388
This patch works around variant test failures which are new to
GCC 8. GCC 8 either doesn't perform SFINAE in lexical order, or
it doesn't halt after encountering the first failure. This
causes hard error to occur instead of substitution failure.
See gcc.gnu.org/PR78489
llvm-svn: 328261
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.
__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).
When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.
This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.
llvm-svn: 328180
When the generated __config file is being used, it is currently only
copied during installation process. However, that means that the file
that gets copied into LLVM build directory is the vanilla __config file,
and any parts of the build that depend on the just built toolchain like
sanitizers will get that instead of the generated version. To avoid this
issue, we need to copy the generated header into the LLVM build
directory as well.
Differential Revision: https://reviews.llvm.org/D43797
llvm-svn: 327194
shrink_to_fit() ends up doing a lot work to get information that we
already know since we just called clear(). This change seems concise
enough to be worth the couple extra lines and my benchmarks show that it
is indeed a pretty decent win. It looks like the same thing is going on
twice in __copy_assign_alloc(), but I didn't want to go overboard since
this is my first contribution to llvm/libc++.
Patch by Timothy VanSlyke!
Differential Revision: https://reviews.llvm.org/D41976
llvm-svn: 327064
This commit indents each level by two space characters, e.g.
#if defined(CONDITION)
# define _LIBCPP_NAME VALUE
#else
# define _LIBCPP_NAME VALUE
#endif
The simple #ifndef, #define, and #endif sequences are not indented, e.g.
#ifndef _LIBCPP_NAME
#define _LIBCPP_NAME ...
#endif
llvm-svn: 326027
Summary:
Certain C libraries require configuration macros defined in __config
to provide the correct functionality for libc++. This patch ensures
that the C header math.h is always included after the __config
header. It also adds a Windows-specific #if guard for the case when
the C math.h file is included the second time, as suggested by
Marshall in https://reviews.llvm.org/rL323490.
Fixes PR36382.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: cfe-commits, pcc, christof, rogfer01
Differential Revision: https://reviews.llvm.org/D43579
llvm-svn: 325760
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
Summary:
Compiling `<functional>` in C++17 or higher mode results in:
```
functional:2500:1: warning: attribute '__visibility__' is ignored, place it after "class" to apply attribute to type declaration [-Wignored-attributes]
_LIBCPP_TYPE_VIS
^
__config:701:46: note: expanded from macro '_LIBCPP_TYPE_VIS'
# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
^
1 warning generated.
```
Fix it by putting the attribute after the `class` keyword.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43209
llvm-svn: 325027
Patch from charlieio@outlook.com
Reviewed as https://reviews.llvm.org/D42354
When the following command is used:
> clang-cl -std:c++17 -Iinclude\c++\v1 hello.cc c++.lib
An error occurred:
In file included from hello.cc:1:
In file included from include\c++\v1\iostream:38:
In file included from include\c++\v1\ios:216:
In file included from include\c++\v1\__locale:15:
In file included from include\c++\v1\string:477:
In file included from include\c++\v1\string_view:176:
In file included from include\c++\v1\__string:56:
In file included from include\c++\v1\algorithm:643:
In file included from include\c++\v1\memory:656:
include\c++\v1\new(165,29): error: redefinition of 'align_val_t'
enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
^
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\vcruntime_new.h(43,16): note:
previous definition is here
enum class align_val_t : size_t {};
^
1 error generated.
vcruntime_new.h has defined align_val_t, libcxx need hide align_val_t.
This patch fixes that error.
llvm-svn: 324853
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
This patch fixes this issue and adds corresponding test cases.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D41992
llvm-svn: 324596
