Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339874 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The macros were inside `#if defined(_LIBCPP_COMPILER_CLANG)`, which means
we would never detect C11 features on non-Clang compilers. According to
Marshall Clow, this is not the intended behavior.
Reviewers: mclow.lists, EricWF
Subscribers: krytarowski, christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50748
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339741 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The current code enables aligned allocation functions when compiling in C++17
and later. This is a problem because aligned allocation functions might not
be supported on the target platform, which leads to an error at link time.
Since r338934, Clang knows not to define __cpp_aligned_new when it's not
available on the target platform -- this commit takes advantage of that to
only use aligned allocation functions when they are available.
Reviewers: vsapsai, EricWF
Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D50344
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339431 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This macro allows hiding symbols from the ABI when the library is built
with an ABI version after ABI v1, which is currently the only stable ABI.
This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be
`_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only
exported by the library for historical reasons are not exported anymore
in the unstable ABI.
Because of that, this commit is an ABI break for ABI v2. This ABI version
is not stable, however, so this should not be a problem.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49914
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339012 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a new macro _LIBCPP_HAS_NO_VECTOR_EXTENSION for detecting
whether a vector extension (\_\_attribute\_\_((vector_size(num_bytes)))) is
available.
On the top of that, this patch implements the following API:
* all constructors
* operator[]
* copy_from
* copy_to
It also defines simd_abi::native to use vector extension, if available.
In GCC and Clang, certain values with vector extension are passed by registers,
instead of memory.
Based on D41148.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits, MaskRay, lichray, sanjoy
Differential Revision: https://reviews.llvm.org/D41376
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338309 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.
It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:
http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.
In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html
Reviewers: EricWF, dexonsmith, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49240
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338122 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338093 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is not guaranteed to work since the characters after '__has_include('
have special lexing rules that can't possibly be applied when
__has_include is generated by a macro. It also breaks the crash reproducers
generated by -frewrite-includes (see https://llvm.org/pr37990).
Reviewers: EricWF, rsmith, mclow.lists
Reviewed By: mclow.lists
Differential Revision: https://reviews.llvm.org/D49067
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337824 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336866 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336382 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336369 91177308-0d34-0410-b5e6-96231b3b80d8
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333351 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333325 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@330360 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329770 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329460 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@328180 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@326027 91177308-0d34-0410-b5e6-96231b3b80d8
An array T[1] isn't necessarily the same say when it's
a member of a struct. This patch addresses that problem and corrects
the tests to deal with it.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@324545 91177308-0d34-0410-b5e6-96231b3b80d8
Some users may have a custom build system which gives a different
name to the libc++ archive (or does not create an archive at all,
instead passing the object files directly to the linker). Give those
users a way to disable auto-linking.
Differential Revision: https://reviews.llvm.org/D42436
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@323300 91177308-0d34-0410-b5e6-96231b3b80d8
Inline the provided "fallback" definitions (which seem to always be
taken) that expand to __cdecl into users. The fallback definitions
for the *CRTIMP* macros were wrong in the case where the CRT is being
linked statically, so define our own macro as a replacement.
Differential Revision: https://reviews.llvm.org/D42158
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@322617 91177308-0d34-0410-b5e6-96231b3b80d8
An application may determine whether the C standard library is glibc
by testing whether __GLIBC_PREREQ is defined. This breaks if libc++
provides its own definition. Instead, define our own macro in our
namespace with the desired semantics.
Differential Revision: https://reviews.llvm.org/D41892
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@322201 91177308-0d34-0410-b5e6-96231b3b80d8
The autolink pragma was missing the pragma name itself. This would
result in the pragma being silently dropped.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@321937 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that this is the only change required in libcxx
for it to compile with the new `wasm32-unknown-unknown-wasm`
target recently added to Clang.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D41073
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@320925 91177308-0d34-0410-b5e6-96231b3b80d8
The MSVC driver and clang do not link against the C++ runtime
explicitly. Instead, they rely on the auto-linking via the pragma
(through `use_ansi.h`) to link against the correct version of the C++
runtime. Attempt to do something similar here so that linking real C++
code on Windows does not require the user to explicitly specify
`c++.lib` when using libc++ as a C++ runtime on windows.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@319816 91177308-0d34-0410-b5e6-96231b3b80d8
Use this source use on Fuchsia where this is the oficially way
to obtain randomness. This could be also used on other platforms
that already support getentropy such as *BSD or Linux.
Differential Revision: https://reviews.llvm.org/D40319
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@319523 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the problem PR31516 with setting locale on Windows by wrapping
_locale_t with a pointer-like class.
Reduces 74 test failures in std/localization test suite to 47 test
failures (on llvm clang, Visual Studio 2015). Number of test failures
doesn't depend on the platform (x86 or x64).
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40181
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@318902 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently `std::variant` always uses an unsigned int to store the variant index. However this isn't nessesary and causes `std::variant` to be larger than it needs to be in most cases.
This patch changes the index type to be `unsigned char` when possible, and `unsigned short` or `unsigned int` otherwise, depending on the size (Although it's questionable if it's even possible to create a variant with 65535 elements.
Unfortunately this change is an ABI break, and as such is only enabled in ABI v2.
Reviewers: mpark
Reviewed By: mpark
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40210
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@318621 91177308-0d34-0410-b5e6-96231b3b80d8
Previously this macro used 0/1 to indicate if it was set.
This is unlike all other libc++ configuration macros which
use ifdef/ifndef.
This patch makes this macro consistent with everything else.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@315995 91177308-0d34-0410-b5e6-96231b3b80d8
Make it clear that these are intended only to force a specific ABI when
the autodetection would give the wrong result by renaming the cmake
options and adding separate forcing macros, as suggested by EricWF in
the post-commit review of r314949 and further discussed on IRC.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@314965 91177308-0d34-0410-b5e6-96231b3b80d8
libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@314949 91177308-0d34-0410-b5e6-96231b3b80d8
