Commit Graph

3182 Commits

Author SHA1 Message Date
Marshall Clow 33566a711d Mark issues 2544, 2567, 2569, 2686 and 2694 as ready/done.
llvm-svn: 283752
2016-10-10 14:15:56 +00:00
Marshall Clow 610ad3a598 Add tests for LWG2544. We already implement this; just adding tests to make sure that we keep doing it.
llvm-svn: 283749
2016-10-10 14:10:45 +00:00
Asiri Rathnayake 30cd7341d0 [libcxx] Add the missing limits.h header
The implementation of [depr.c.headers] in D12747 introduced the necessary
C headers into libc++. This patch adds one more missing headers: limits.h

We spotted this due to a failing C++03 test [limits_h.pass.cpp] in our libc++
configuration; when the limits.h header is included from a C++ program, it now
bypassed the __config header and went directly into the underlying C library's
limits.h header, which is problematic for us because we use __config header to
configure the underlying C library's behaviour when used from a C++ context.

Reviewers: mclow.lists, rsmith

Differential revision: https://reviews.llvm.org/D25361

llvm-svn: 283726
2016-10-10 08:38:51 +00:00
Eric Fiselier ed84f4abd4 Cleanup CMake status output
llvm-svn: 283721
2016-10-10 06:31:00 +00:00
Eric Fiselier ac473034fc Provide a constexpr addressof with GCC 7.
__builtin_addressof was added to the GCC trunk in the past week. This patch
teaches libc++ about it so it can correctly provide constexpr addressof.

Unfortunately this patch will break users of earlier GCC 7 builds, since
we expect __builtin_addressof but one won't be provided. One option would be
to only use __builtin_addressof for GCC 7.1 and above, but that means
waiting for another release.

Instead I've specifically chosen to break older GCC 7 versions. Since GCC 7
has yet to be released, and the 7.0 release is a development release, I
believe that anybody currently using GCC 7.0 will have no issue upgrading.

llvm-svn: 283715
2016-10-10 05:34:18 +00:00
Eric Fiselier 99b81a59fb Workaround missing C++14 constexpr semantics in filesystem
llvm-svn: 283714
2016-10-10 05:19:59 +00:00
Eric Fiselier a52ce7fd03 Remove use of int128_t inside the filesystem implementation
llvm-svn: 283712
2016-10-10 04:22:58 +00:00
Eric Fiselier 6912539717 Remove debug output from gen_linker_script.py
llvm-svn: 283701
2016-10-09 21:43:30 +00:00
Eric Fiselier 054fc4cef6 Fix linker script generation for in-tree builds
llvm-svn: 283700
2016-10-09 21:34:03 +00:00
Hal Finkel 5b5f4f0c74 [CMake] Fix in-tree libcxxabi build support after r283659
r283659 changed the argument to gen_link_script.py from SCRIPT_ABI_LIBNAME to
LIBCXX_LIBRARIES_PUBLIC, assuming that all of the items in the
LIBCXX_LIBRARIES_PUBLIC list were library names. This is not right, however,
for in-tree libcxxabi builds, we might have the target name in this list. There
was special logic to fixup SCRIPT_ABI_LIBNAME for this situation; change it to
apply a similar fixup for LIBCXX_LIBRARIES_PUBLIC.

llvm-svn: 283684
2016-10-09 02:49:31 +00:00
Michal Gorny 2433b26176 [cmake] Split linked libraries into private & public, for linker script
Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that
holds 'public' interface libraries -- that is, libraries that both
libc++ links to and programs linked against it need to link to.

Currently this includes the ABI library and optionally -lunwind (when
LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the
linker script, in order to make it possible to link C++ programs using
clang with compiler-rt runtime out-of-the-box.

Differential Revision: https://reviews.llvm.org/D25008

llvm-svn: 283659
2016-10-08 10:27:45 +00:00
Eric Fiselier f03ffb2c9b Remove all _LIBCPP_VERSION tests from under test/std
llvm-svn: 283644
2016-10-08 01:32:56 +00:00
Eric Fiselier e58baed3a3 Purge all usages of _LIBCPP_STD_VER under test/std/algorithm
llvm-svn: 283643
2016-10-08 01:25:23 +00:00
Eric Fiselier b10fc37096 Add missing <memory> include in test
llvm-svn: 283633
2016-10-08 00:59:16 +00:00
Eric Fiselier 653179b77b Add missing include in test_allocator.h
llvm-svn: 283632
2016-10-08 00:57:56 +00:00
Eric Fiselier 69a4f66114 [libc++] Fix stack_allocator
Summary:
To quote STL the problems with stack allocator are"

>"stack_allocator<T, N> is seriously nonconformant to N4582 17.6.3.5 [allocator.requirements].
> First, it lacks a rebinding constructor. (The nested "struct rebind" isn't sufficient.)
> Second, it lacks templated equality/inequality.
> Third, it completely ignores alignment.
> Finally, and most severely, the Standard forbids its existence. Allocators are forbidden from returning memory "inside themselves". This requirement is implied by the Standard's requirements for rebinding and equality. It's permitted to return memory from a separate buffer object on the stack, though."

This patch attempts to address all of those issues.

First, instead of storing the buffer inside the allocator I've change `stack_allocator` to accept the buffer as an argument.

Second, in order to fix rebinding I changed the parameter list from `<class T, size_t NumElements>` to `<class T, size_t NumBytes>`. This allows allocator rebinding
between types that have different sizes. 

Third, I added copy and rebinding constructors and assignment operators.

And finally I fixed the allocation logic to always return properly aligned storage.



Reviewers: mclow.lists, howard.hinnant, STL_MSFT

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25154

llvm-svn: 283631
2016-10-08 00:56:22 +00:00
Marshall Clow 33b87bffc6 Disable alignment support of 0x4000 for Win32. https://reviews.llvm.org/D25053
llvm-svn: 283621
2016-10-07 23:19:04 +00:00
Eric Fiselier e4d80542d2 Fix PR30642 - libc++ leaks always-visible symbols into programs
This was caused by r281673, specifically changing `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS`
from `__attribute__((__type_visibility__("default")))` to
`__attribute__((__visibility("default")))`.

I made that change because I thought the external instantiations needed
their members to have default visibility. However since libc++ never builds
with -fvisibility=hidden this appears not to be needed. Instead this change
caused previously hidden inline methods to become un-hidden, which is a regression.

This patch reverts the problematic change and fixes PR30642.

llvm-svn: 283620
2016-10-07 23:07:59 +00:00
Eric Fiselier 609e669e1a Fix shadow warnings. Patch from STL@microsoft.com
llvm-svn: 283618
2016-10-07 22:10:35 +00:00
Eric Fiselier b18fd9654f Fix various issues in std::any and the related tests.
* Fix self-swap. Patch from Casey Carter.

* Remove workarounds and tests for types with deleted move constructors. This
  was originally added as part of a LWG proposed resolution that has since
  changed.

* Re-apply most recent PR for LWG 2769.

* Re-apply most recent PR for LWG 2754. Specifically fix the SFINAE checks to
  use the decayed type.

* Fix tests to allow moved-from std::any's to have a non-empty state. This is
  the behavior of MSVC's std::any.

* Various whitespace and test fixes.

llvm-svn: 283606
2016-10-07 21:27:45 +00:00
Eric Fiselier 89c9191447 Remove MSVC workarounds. Patch from STL@microsoft.com
llvm-svn: 283580
2016-10-07 18:51:33 +00:00
Marshall Clow c036604f9b Mark issues 2514, 2519, 2536 and 2475 as done
llvm-svn: 283452
2016-10-06 13:59:18 +00:00
Asiri Rathnayake 08eb2148ff [libcxx] Recover no-exceptions XFAILs - I
First batch of changes to get some of these XFAILs working in the
no-exceptions libc++ variant.

Changed some XFAILs to UNSUPPORTED where the test is all about exception
handling. In other cases, used the test macros TEST_THROW and
TEST_HAS_NO_EXCEPTIONS to conditionally exclude those parts of the test
that concerns exception handling behaviour.

Reviewers: EricWF, mclow.lists

Differential revision: https://reviews.llvm.org/D24562

llvm-svn: 283441
2016-10-06 11:15:41 +00:00
Eric Fiselier ae34c56ee7 Fix strict-aliasing violation in typeinfo::hash_code()
Summary:
The current implementation of `hash_code()` for uniqued RTTI strings violates strict aliasing by dereferencing a type-punned pointer. Specifically it generates a `const char**` pointer from the address of the `__name` member before casting it to `const size_t*` and dereferencing it to get the hash. This is really just a complex and incorrect way of writing `reinterpret_cast<size_t>(__name)`.

This patch changes the conversion sequence so that it no longer contains UB.


Reviewers: howard.hinnant, mclow.lists

Subscribers: rjmccall, cfe-commits

Differential Revision: https://reviews.llvm.org/D24012

llvm-svn: 283408
2016-10-05 22:55:10 +00:00
Marshall Clow 23c725ebdf Comment out failing test while I figure out who is at fault
llvm-svn: 283360
2016-10-05 18:47:18 +00:00
Marshall Clow e81d2fa9bb Mark LWG#2679 as complete
llvm-svn: 283356
2016-10-05 18:36:24 +00:00
Marshall Clow cd1e532c39 Mark LWG#2358 as done
llvm-svn: 283341
2016-10-05 17:02:43 +00:00
Marshall Clow d836a9d5f1 Make tests for is_empty better. No functional change.
llvm-svn: 283339
2016-10-05 17:01:16 +00:00
Marshall Clow 67be6ff839 Add another append test for basic_string
llvm-svn: 283331
2016-10-05 15:47:13 +00:00
Marshall Clow 592024759e Mark LWG issues 2221, 2556 and 2589 as complete
llvm-svn: 283325
2016-10-05 15:21:11 +00:00
Eric Fiselier 015839a555 [libcxx] [test] Guard __has_include usage with a macro
Summary: There's a macro scheme already being used for __has_feature etc. Use it for __has_include too, which makes MSVC happy (it doesn't support __has_include yet, and unguarded use explodes horribly).

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25251

llvm-svn: 283260
2016-10-04 21:25:51 +00:00
Marshall Clow af63ab2b69 Mark #2759 as ready and #2755 as complete
llvm-svn: 283222
2016-10-04 14:39:58 +00:00
Marshall Clow 6203c91eac Mark #2598 as ready
llvm-svn: 283220
2016-10-04 14:08:50 +00:00
Marshall Clow f21aa87f3b Mark #2739 as ready
llvm-svn: 283218
2016-10-04 13:41:56 +00:00
Marshall Clow da68203678 Mark a couple more Issaquah issues as done: 2578 and 2738
llvm-svn: 283163
2016-10-03 23:42:31 +00:00
Marshall Clow f2464a9301 Change a couple of 'template <typename's to 'template <class' which is what we use in the rest of the library.
llvm-svn: 283162
2016-10-03 23:40:48 +00:00
Marshall Clow 53abcbd8a9 Add tests to make sure that is_constructible<cv-void> is false. We already checked 'unqualified void'. This was brought up by LWG#2738
llvm-svn: 283161
2016-10-03 23:39:52 +00:00
Marshall Clow a5554a93de Mark a couple issues as done (2742 and 2760)
llvm-svn: 283124
2016-10-03 17:35:08 +00:00
Logan Chien 45e8ba88c3 [lit] Allow more file extensions for test cases.
This commit splits the file extensions before determining the test
format.  This allows libc++abi to add assembly-based test cases.

llvm-svn: 283118
2016-10-03 16:00:22 +00:00
Marshall Clow bfdc374212 Change titie of page from Oulu to Issaquah
llvm-svn: 283113
2016-10-03 14:24:21 +00:00
Marshall Clow a82e92867f List tentatively ready issues for Issaquah
llvm-svn: 283112
2016-10-03 14:23:04 +00:00
Hal Finkel 6f557b9f12 Remove some additional unnecessary std:: in cmath
Unlike in math.h, as Eric pointed out in the review of D18639, we don't need
the std:: in cmath.

llvm-svn: 283052
2016-10-01 20:38:44 +00:00
Hal Finkel ae22f0b242 Use __builtin_isnan/isinf/isfinite in complex
The libc-provided isnan/isinf/isfinite macro implementations are specifically
designed to function correctly, even in the presence of -ffast-math (or, more
specifically, -ffinite-math-only). As such, on most implementation, these
either always turn into external function calls (e.g. glibc) or are
specifically function calls when FINITE_MATH_ONLY is defined (e.g. Darwin).

Our implementation of complex arithmetic makes heavy use of isnan/isinf/isfinite
to deal with corner cases involving non-finite quantities. This was problematic
in two respects:

  1. On systems where these are always function calls (e.g. Linux/glibc), there was a
     performance penalty
  2. When compiling with -ffast-math, there was a significant performance
     penalty (in fact, on Darwin and systems with similar implementations, the code
     may in fact be slower than not using -ffast-math, because the inline
     definitions provided by libc become unavailable to prevent the checks from
     being optimized out).

Eliding these inf/nan checks in -ffast-math mode is consistent with what
happens with libstdc++, and in my experience, what users expect. This is
critical to getting high-performance code when using complex<T>. This change
replaces uses of those functions on basic floating-point types with calls to
__builtin_isnan/isinf/isfinite, which Clang will always expand inline. When
using -ffast-math (or -ffinite-math-only), the optimizer will remove the checks
as expected.

Differential Revision: https://reviews.llvm.org/D18639

llvm-svn: 283051
2016-10-01 20:38:31 +00:00
Eric Fiselier 2c8c71f13e Remove all instances of _LIBCPP_HAS_NO_RVALUE_REFERENCES from test/std/utilities
llvm-svn: 283032
2016-10-01 10:46:01 +00:00
Eric Fiselier f18891050b Replace test_throw.h header with a single test macro
llvm-svn: 283030
2016-10-01 10:34:13 +00:00
Shoaib Meenai c6f93e389e [libc++] Add missing locale aliases
Add underscore aliases for strtof_l and strtod_l. _strtold_l exists in
VS 2013 and above, so fix that definition as a drive-by fix.

Differential Revision: https://reviews.llvm.org/D25059

llvm-svn: 282681
2016-09-29 03:35:41 +00:00
Eric Fiselier 790ad869ac Partially revert overflow checking in last_write_time
llvm-svn: 282660
2016-09-29 01:01:26 +00:00
Shoaib Meenai 3888eb66b0 [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows
Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY,
and clarify why the operator new and delete family of functions are
marked dllexport when building but *not* dllimport when including the
header externally.

The new code is identical to the intent of the old code (and would be
functionally equivalent were cxx_EXPORTS still defined when building
libc++). The overall behavior is not ideal, since Microsoft's operator
new and delete functions will get called instead of libc++'s, but I
think consistently calling msvcrt's functions is better than either
calling msvcrt's or libc++'s functions depending on header inclusion.

Differential Revision: https://reviews.llvm.org/D25042

llvm-svn: 282644
2016-09-28 22:28:51 +00:00
Eric Fiselier ea117bf9ad Mark libc++ internal globals with _LIBCPP_SAFE_STATIC.
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
2016-09-28 22:08:13 +00:00
Eric Fiselier 09cc08654a Improve 'last_write_time(...)' accuracy and detect overflow errors.
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
2016-09-28 21:16:58 +00:00
Michal Gorny 0e40bee847 Revert r282483 - [cmake] Add linker option "-Wl,-z,defs" in standalone build
Revert r282483 as it causes build failures due to missing symbols when
not linking to -lgcc_s (i.e. doing pure LLVM stack build). The patch can
be reintroduced when the build system is fixed to add all needed
libraries (libunwind, compiler-rt).

llvm-svn: 282524
2016-09-27 18:54:02 +00:00
Michal Gorny 4601ac04c7 [cmake] Add linker option "-Wl,-z,defs" in standalone build
Add the "-Wl,-z,defs" linker option that is used to prevent
underlinking. It is already used by LLVM itself but does not get
propagated into stand-alone build of libc++. This patch ensures
that the option is passed in independently of whether libc++ is built
in-tree or out-of-tree.

Patch by Lei Zhang.

Differential Revision: https://reviews.llvm.org/D24119

llvm-svn: 282483
2016-09-27 12:15:35 +00:00
Michal Gorny ecc88642d4 [cmake] Strip possibly-inherited compiler flags in in-tree build only
Strip the set of flags (including debug defs, -m32) that could
be inherited from top-level LLVM build only when in-tree build is
performed. This prevents libcxx from confusingly and undesiredly
stripping user-supplied flags e.g. when performing packaging system
controlled multi-ABI build.

Otherwise, in order to perform 32-bit builds the build scripts would
have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many
different ABI flags for different targets, and it really makes no sense
to add separate CMake options for each possible -m* flag and then keep
a mapping from well-known flags to the custom CMake options.

Differential Revision: https://reviews.llvm.org/D24809

llvm-svn: 282475
2016-09-27 07:55:26 +00:00
Eric Fiselier 55089ce834 Fix possible division by zero
llvm-svn: 282468
2016-09-27 02:13:27 +00:00
Eric Fiselier efc962cd06 Remove out of date items in TODO.txt
llvm-svn: 282466
2016-09-27 01:28:47 +00:00
Eric Fiselier 5464421608 Expect DLL builds on Windows by default and require a custom __config for static
builds.

On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.

This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.

This patch is based off work by Shoaib Meenai.

llvm-svn: 282449
2016-09-26 22:19:41 +00:00
Oleg Ranevskyy eef9b35c6d [libc++] Fix typos causing compilation errors when _LIBCPP_DEBUG_LEVEL >= 2
Summary: This patch fixes a couple of typos that cause compilation errors when application includes <unordered_map> and enables the libc++'s debugging capabilities.

Reviewers: EricWF

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D24883

llvm-svn: 282446
2016-09-26 21:39:38 +00:00
Eric Fiselier c24e6dd3c8 [libc++] Extension: Make `move` and `forward` constexpr in C++11.
Summary:
`std::move` and `std::forward` were not marked constexpr in C++11.  This can be very damaging because it makes otherwise constant expressions non-constant. For example:

```
#include <utility>
template <class T>
struct Foo {
  constexpr Foo(T&& tx) :  t(std::move(tx)) {}
  T t;
};
[[clang::require_constant_initialization]] Foo<int> f(42); // Foo should be constant initialized but C++11 move is not constexpr. As a result `f` is an unsafe global.
```

This patch applies `constexpr` to `move` and `forward` as an extension in C++11. Normally the library is not allowed to add `constexpr` because it may be observable to the user. In particular adding constexpr may cause valid code to stop compiling. However these problems only happen in more complex situations, like making `__invoke(...)` constexpr. `forward` and `move` are simply enough that applying `constexpr` is safe. 

Note that libstdc++ has offered this extension since at least 4.8.1.

Most of the changes in this patch are simply test cleanups or additions. The main changes in the tests are:

* Fold all `forward_N.fail.cpp` tests into a single `forward.fail.cpp` test using -verify.
* Delete most `move_only_N.fail.cpp` tests because they weren't actually testing anything.
* Fold `move_copy.pass.cpp` and `move_only.pass.cpp` into a single `move.pass.cpp` test.
* Add return type and noexcept tests for `forward` and `move`.




Reviewers: rsmith, mclow.lists, EricWF

Subscribers: K-ballo, loladiro

Differential Revision: https://reviews.llvm.org/D24637

llvm-svn: 282439
2016-09-26 20:55:02 +00:00
Michal Gorny 9eddaeb534 [include] Declare __STDC_*_MACROS for C++11 compat in old libc
Declare __STDC_FORMAT_MACROS, __STDC_LIMIT_MACROS and
__STDC_CONSTANT_MACROS before including real inttypes.h/stdint.h when
the wrapper-header is included in C++11, in order to enable
the necessary macros in C99-compliant libc.

The C99 standard defined that the format macros in inttypes.h should be
defined by the C++ implementations only when __STDC_FORMAT_MACROS is
defined, and the limit and constant macros in stdint.h should be defined
only when __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined
appropriately. Following this specification, multiple old versions of
glibc up to 2.17 do not define those macros by default for C++,
rendering the libc++ headers non-compliant to the C++11 standard.

In order to achieve the necessary compliance, __STDC_FORMAT_MACROS is
defined in wrapped inttypes.h just before including the system
inttypes.h, when C++11 or newer is used. Both __STDC_LIMIT_MACROS
and __STDC_CONSTANT_MACROS are defined in newly-wrapped stdint.h. This
fixes the C++11 compliance while preserving the current behavior for
C++03.

Differential Revision: https://reviews.llvm.org/D24903

llvm-svn: 282435
2016-09-26 20:20:00 +00:00
Eric Fiselier 221f689f3b Update -verify test to use new static assert message
llvm-svn: 282352
2016-09-25 08:30:05 +00:00
Eric Fiselier 4271d0148a Fix missing _LIBCPP_INLINE_VISIBILITY macro on C++03 specific __hash_table function
llvm-svn: 282349
2016-09-25 04:05:46 +00:00
Eric Fiselier 54613ab4d4 [libc++] Remove various C++03 feature test macros
Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.

This patch removes the __config macros:

* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT

As a drive I also changed our C++03 static_assert to use _Static_assert if available.

I plan to commit this without review if nobody voices an objection.

Reviewers: mclow.lists

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D24895

llvm-svn: 282347
2016-09-25 03:34:28 +00:00
Eric Fiselier 9e1b0b5b78 Use __attribute__((internal_linkage)) when available.
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
2016-09-25 03:14:13 +00:00
Marshall Clow a8fd1e4be0 Fix a few static_asserts that need extra parens on -03
llvm-svn: 282343
2016-09-24 23:52:21 +00:00
Marshall Clow 54f0981ebd Implement proposed resolution for LWG#2758. Reviewed as D24446. Normally, I would wait for these to be voted upon at a committee meeting (November), but the current draft standard is broken, and this should fix it. (And if it doesn't, we want to know about it soonest)
llvm-svn: 282342
2016-09-24 22:45:42 +00:00
Marshall Clow 450370f3c8 Fix incorrect include in is_error_code_enum.pass.cpp
llvm-svn: 282332
2016-09-24 18:16:53 +00:00
Marshall Clow e69a08ba6d Implement is_error_code_v and is_error_condition_v for c++17. Rework the tests for is_error_code and is_error_condition, since they were really lacking. Thanks to Alisdair for the heads-up that we were missing these.
llvm-svn: 282331
2016-09-24 17:36:14 +00:00
Shoaib Meenai 4e14445e59 [libc++] Remove math_win32.h
Visual Studio 2013 and onward have all the required functions in their
CRT headers, and we don't support older versions anymore.

Differential Revision: https://reviews.llvm.org/D24879

llvm-svn: 282328
2016-09-24 06:27:28 +00:00
Marshall Clow c669522a26 Fix failure on 03 bot
llvm-svn: 282134
2016-09-22 03:25:22 +00:00
Marshall Clow a48055cee3 Add missing _v traits. is_bind_expression_v, is_placeholder_v and uses_allocator_v
llvm-svn: 282126
2016-09-22 00:23:15 +00:00
Dan Albert bc40821ee3 Fix signatures of fallback tow(upper|lower)_l.
Summary:
These functions take and return wint_t, not int:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/towupper.html

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D24743

llvm-svn: 281936
2016-09-19 20:42:57 +00:00
Shoaib Meenai 190994e435 [libc++] Fix extern template visibility for Windows
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
2016-09-19 18:29:07 +00:00
Dan Albert c991709f46 Replace __ANDROID__ with __BIONIC__.
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
2016-09-19 18:00:45 +00:00
Shoaib Meenai 3b33938c05 [libc++] Fix inline attribute for non-MSVC Windows
gcc and clang in gcc compatibility mode do not accept __forceinline. Use
the gcc attribute for them instead.

Differential Revision: https://reviews.llvm.org/D24678

llvm-svn: 281766
2016-09-16 19:12:54 +00:00
Asiri Rathnayake a6199170ac [libcxx] Add missing c++98 xfail. NFC.
This is the only test failing in c++98 mode at the moment.

llvm-svn: 281731
2016-09-16 14:32:19 +00:00
Eric Fiselier 8e68d6a023 Attempt to fix Sphinx build
llvm-svn: 281697
2016-09-16 03:47:53 +00:00
Eric Fiselier 991c354b01 Update _LIBCPP_EXCEPTION_ABI doc with @mclow's feedback
llvm-svn: 281695
2016-09-16 02:51:26 +00:00
Eric Fiselier e0d2d58ff7 Move _LIBCPP_INLINE_VISIBILITY to first declaration in <propagate_const>
llvm-svn: 281692
2016-09-16 02:16:23 +00:00
Eric Fiselier 1e033439ba Move _LIBCPP_INLINE_VISIBILITY to first declaration in sstream.
llvm-svn: 281691
2016-09-16 02:09:26 +00:00
Eric Fiselier 1fbaf535d6 Use _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY in valarray to support attribute((internal_linkage)).
The externally instantiated member functions must be declared using
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY, not _LIBCPP_INLINE_VISIBILITY, in
order to be properly exported when using __attribute__((internal_linkage)).

Otherwise the explicit instantiations will obviously have internal linkage and
will not be exported from the dylib.

llvm-svn: 281684
2016-09-16 00:13:55 +00:00
Eric Fiselier 1b17a4b7b4 Move inline attributes in filesystem to first declaration
llvm-svn: 281683
2016-09-16 00:07:16 +00:00
Eric Fiselier f8f31c4985 [libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI compatibility
Summary:
GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'.  

```
// RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
// RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
#define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline))

template <class T>
struct Foo {
  void foo();
  void bar();
};

template <class T>
void Foo<T>::foo() {}

template <class T>
inline INLINE_VISIBILITY
void Foo<T>::bar() {}

template struct Foo<int>;
```

This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated). 

Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline`  therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors).

This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`.

After applying this patch GCC dylibs now contain:
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_`
  * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv`
  * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw`
  * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE`
  * `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi`
  * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_`
  * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl`
  * `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv`
  * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE`
  * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw`
  * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw`


This patch has no effect on Clang based builds.



Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF

Subscribers: beanz, cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D24600

llvm-svn: 281681
2016-09-16 00:00:48 +00:00
Eric Fiselier 49e2967f27 [libc++] Fix and document visibility attributes for Clang, GCC and Windows.
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!

This patch adds two new visibility macros:

* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.

After applying this patch GCC only emits one -Wattribute warning opposed to 30+.


Reviewers: mclow.lists, EricWF

Subscribers: beanz, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D24602

llvm-svn: 281673
2016-09-15 22:27:07 +00:00
Shoaib Meenai f6eea04cd1 [libc++] Avoid <memory> include in locale_win32.h
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
2016-09-15 18:36:13 +00:00
Kuba Brecka 50bc34ca31 [libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneously
Allow building with LLVM_USE_SANITIZER=“Address;Undefined” (and “Undefined;Address”).

Differential Revision: https://reviews.llvm.org/D24569

llvm-svn: 281603
2016-09-15 11:04:53 +00:00
Eric Fiselier a75c1bf9f6 Revert r280944 - Added 'inline' attribute to basic_string's destructor
This patch causes a couple of issues:

1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++
bug it breaks the LLVM build using libc++. Reverting this patch is only
a temporary workaround until Clang is fixed.

2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC.
Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line
definition when compiling the dylib. This causes the externally instantiated
~basic_string symbol to have hidden visibility.

This patch should be recommitted after addressing (1) and (2). (2) can be fixed
by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as
__attribute__((visibility("default"), always_inline)) as opposed to
_LIBCPP_INLINE_VISIBILITY which makes the symbol hidden.

llvm-svn: 281562
2016-09-14 23:52:01 +00:00
Kuba Brecka f239e6b7a2 [libcxx] Add a TSan regression test for a data race in call_once
Differential Revision: https://reviews.llvm.org/D24297

llvm-svn: 281477
2016-09-14 14:15:42 +00:00
Kuba Brecka eec85de4c0 [libcxx] Fix a typo in test/libcxx/test/target_info.py that prevents running tests on Darwin with sanitizers
Differential Revision: https://reviews.llvm.org/D24297

llvm-svn: 281476
2016-09-14 14:13:50 +00:00
Kuba Brecka d634df526d [libcxx] Enable building and testing of libcxx with ThreadSanitizer on OS X
This patch enables building and testing libcxx under ThreadSanitizer on OS X. CMake builds that have -DLLVM_USE_SANITIZER=Thread will automatically build libcxx with -fsanitize=thread and testing via lit then runs under TSan.

Differential Revision: https://reviews.llvm.org/D24297

llvm-svn: 281475
2016-09-14 14:12:50 +00:00
Asiri Rathnayake d547ac0df9 [libcxx] Fix gcc builds.
Step around a gcc pre-processor defect which causes it to fail to
parse the __has_include macro check.

llvm-svn: 281310
2016-09-13 09:32:32 +00:00
Shoaib Meenai 7afc8fa44c config: Use _LIBCPP_TYPE_VIS_ONLY with enum class
An enum class has associated type info. In the Microsoft ABI, type info
is emitted in the COMDAT section and isn't exported, so clang rightfully
complains about __declspec(dllexport) being unused for an enum class.
On other platforms, we still want to export the type info.

Differential Revision: https://reviews.llvm.org/D24065

llvm-svn: 281264
2016-09-12 21:41:12 +00:00
Shoaib Meenai 4f671370eb config: Fix typo in comment
Testing commit access. NFC.

llvm-svn: 281250
2016-09-12 20:14:44 +00:00
Asiri Rathnayake 8c2bf45da9 [libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:

- Building libc++ against a thread library other than pthreads.

- Building libc++ with an "external" thread API, allowing a separate library to
  provide the implementation of that API.

The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.

For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.

Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.

When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).

Differential revision: https://reviews.llvm.org/D21968

Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-11 21:46:40 +00:00
Saleem Abdulrasool 0fbd53434d support: clean up MSVC support
Visual Studio 2013 (CRT version 12) added support for many C99 long long and
long double functions. Visual Studio 2015 (CRT version 14) increased C99 and C11
compliance further. Since we don't support Visual Studio versions older than
2013, we can considerably clean up the support header.

Patch by Shoaib Meenai!

llvm-svn: 280988
2016-09-08 20:52:48 +00:00
Aditya Kumar b839888af8 Added 'inline' attribute to basic_string's destructor
Author: laxmansole

Reviewers: howard.hinnant
           mclow.lists
Subscribers: EricWF, flyingforyou, evandro

Differential Revision: https://reviews.llvm.org/D22834

Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string().
Worked in collaboration with Aditya Kumar.

llvm-svn: 280944
2016-09-08 14:31:44 +00:00
Eric Fiselier 94b812ac77 Avoid compile error by giving the test type a user defined default constructor
llvm-svn: 280780
2016-09-07 03:50:36 +00:00
Marshall Clow a77bb8ef34 Fix PR#30303 - no matching function for call to '__ptr_in_range'
llvm-svn: 280779
2016-09-07 03:32:06 +00:00
Eric Fiselier f8e7a54be8 Improve constexpr tests for std::any
llvm-svn: 280777
2016-09-07 02:38:48 +00:00
Eric Fiselier c1d527d3d8 Fix PR30260 - optional<const T> not working.
This patch fixes PR30260 by using a (void*) cast on the placement argument
to placement new to casts away the const. See also http://llvm.org/PR30260.

As a drive by change this patch also changes the header guard for
<experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL.

llvm-svn: 280775
2016-09-07 01:56:07 +00:00
Eric Fiselier 309a50aefb Enable installation of libc++experimental by default.
When libc++experimental was originally created it was empty and therefore there
was no reason to install it. Now that the library contains
<experimental/memory_resource> and <experimental/filesystem> there is a good
reason to install it.

Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY
is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true.

llvm-svn: 280773
2016-09-07 01:15:10 +00:00
Eric Fiselier e9e3377141 Improve CMake output when registering benchmarks
llvm-svn: 280771
2016-09-07 00:57:26 +00:00
Eric Fiselier b683ec20e4 Try 2 - Remove <cstdlib> include from `<exception>`
This patch removes the `<cstdlib>` include from exception where it is no longer
needed. Unlike my previous attempt this patch also adds <cstdlib> where needed
in other headers like <new> and <typeinfo>.

This won't fix the Firefox build issues discussed on IRC but it is more correct
for libc++.

llvm-svn: 280754
2016-09-06 21:25:27 +00:00
Eric Fiselier 350eb52819 Revert r280743 and r280745. Remove <cstdlib> include from `<exception>`
Apparently I missed a number of additional include which need to be added.
Reverting so I can recommit as a single patch with all of the required includes.

llvm-svn: 280752
2016-09-06 21:06:41 +00:00
Eric Fiselier b0b1746962 Add missing <cstdlib> include. Sorry about the bot breakage
llvm-svn: 280745
2016-09-06 20:10:13 +00:00
Eric Fiselier 36103e868b Remove unneeded includes in <exception> after removing __libcpp_throw
llvm-svn: 280743
2016-09-06 19:56:40 +00:00
Marshall Clow 7e1a23001d Fix Bug 30240 - std::string: append(first, last) error when aliasing. Add test cases for append/insert/assign/replace while we're at it, and fix a similar bug in insert.
llvm-svn: 280643
2016-09-05 01:54:30 +00:00
Kuba Brecka 224264ade0 [libcxx] Fix a data race in call_once
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
2016-09-04 09:55:12 +00:00
Eric Fiselier 8e571b551e Apply curr_symbol.pass.cpp test fix to missed test case
llvm-svn: 280612
2016-09-04 04:09:25 +00:00
Eric Fiselier f49fe8f2b6 Fix bad locale test data when using the newest glibc
llvm-svn: 280608
2016-09-04 00:48:54 +00:00
Marshall Clow 2a837eae39 Mark test as XFAIL for C++03, rather than providing a dummy pass.
llvm-svn: 280605
2016-09-04 00:37:06 +00:00
Eric Fiselier ff94d25063 Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context.
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
2016-09-03 08:07:40 +00:00
Eric Fiselier ebbcfe7bfc memory_resource still needs init_priority when built with GCC 4.9
llvm-svn: 280585
2016-09-03 07:05:40 +00:00
Eric Fiselier 4efaa30934 Define _LIBCPP_SAFE_STATIC __attribute__((require_constant_initialization)), and apply it to memory_resource
llvm-svn: 280561
2016-09-03 00:11:33 +00:00
Dimitry Andric 54150db232 Avoid narrowing warnings in __bitset constructor
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
2016-09-02 21:02:11 +00:00
Saleem Abdulrasool e68b47070f cstdio: limit gets to CRT versions below 14
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
2016-09-01 21:09:19 +00:00
Saleem Abdulrasool 394d351ad7 build: don't add -fPIC on Windows
`-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
2016-09-01 20:49:54 +00:00
Chris Bieneman a78187a385 [CMake] NFC. Missed the other uses in r280406
Doh! Obviously need to slow down.

llvm-svn: 280407
2016-09-01 19:47:39 +00:00
Chris Bieneman 1c4b97083d [CMake] NFC. Fixing spelling from r280400
Doh!

llvm-svn: 280406
2016-09-01 19:46:02 +00:00
Chris Bieneman bd715f84a4 [CMake] Don't copy headers on fully standalone
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
2016-09-01 18:46:53 +00:00
Ivan Krasin c735b902a9 Fix libc++ configuration with -fsanitize-coverage
Summary:
a recent change (r280015) in libc++ configuration broke LibFuzzer bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/12245

It's not restricted just to that bot; any code that uses the sanitize coverage and configures libc++ hits it.

This CL fixes the issue.

Reviewers: compnerd

Subscribers: aizatsky

Differential Revision: https://reviews.llvm.org/D24116

llvm-svn: 280335
2016-09-01 01:38:32 +00:00
Chris Bieneman 0e4c73b24d [CMake] Copy headers relative to LLVM_BINARY_DIR
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
2016-08-30 16:51:34 +00:00
Eric Fiselier ea982ed35a Add "FLAKY_TEST" test directive to support re-running flaky tests.
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
2016-08-30 01:46:43 +00:00
Eric Fiselier 7a05dfa791 Fix syntax error in recent CMake change.
llvm-svn: 280042
2016-08-30 01:10:33 +00:00
Eric Fiselier 21125869ed Fix PR28831 - Bad logic around CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES.
See https://llvm.org/bugs/show_bug.cgi?id=28831 for more information about
the changes.

llvm-svn: 280037
2016-08-30 00:54:37 +00:00
Saleem Abdulrasool 124186616a libc++: perform configuration checks with -nodefaultlibs
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
2016-08-29 21:33:37 +00:00
Eric Fiselier f6ac565031 Fix or suppress GCC warnings during build.
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
2016-08-29 20:43:38 +00:00
Eric Fiselier 8b4a30584a Turn On -DLIBCXX_ENABLE_BENCHMARKS by default.
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
2016-08-29 19:50:49 +00:00
Eric Fiselier 4d5e91d307 Update Google Benchmark library.
llvm-svn: 279989
2016-08-29 19:12:01 +00:00
Eric Fiselier 4268a742f5 Fix pair::operator=(TupleLike&&).
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
2016-08-29 01:43:41 +00:00
Eric Fiselier 67c2344174 Revert r279953 - Fix pair::operator=(TupleLike&&)
The test emits warnings causing the test-suite to fail. Since I want this
patch merged into 3.9 I'll recommit it with a clean test.

llvm-svn: 279954
2016-08-29 01:39:54 +00:00
Eric Fiselier 0678cc793a Fix pair::operator=(TupleLike&&).
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
2016-08-29 01:09:47 +00:00
Eric Fiselier e7154709e0 Implement C++17 std::sample.
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
2016-08-28 22:14:37 +00:00
Eric Fiselier 040411762f Mark LWG 2716 as complete - shuffle and sample disallows lvalue URNGs.
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
2016-08-28 21:55:00 +00:00
Eric Fiselier 2fc65041be Implement LWG 2711. Constrain path members.
llvm-svn: 279945
2016-08-28 21:26:01 +00:00
Eric Fiselier a13a2056f6 [Docs] Update libc++ target names after r279675.
llvm-svn: 279940
2016-08-28 18:33:08 +00:00
Dimitry Andric f8563f3206 Avoid embedded preprocessor directives in __tree
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
2016-08-27 19:32:03 +00:00
Aditya Kumar d51f2a2a64 Add attribute noreturn to functions that throw
Reviewers: mclow.lists, EricWF, howard.hinnant, sebpop
Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D21232

llvm-svn: 279903
2016-08-27 02:26:42 +00:00
Marshall Clow 0fc8cec796 Followon to r279744. Find the other exception types and make __throw_XXX routines (and call them). Remove the generic __libcpp_throw routine, since no one uses it anymore.
llvm-svn: 279763
2016-08-25 17:47:09 +00:00
Marshall Clow 567a1d0478 Remove duplicate inline
llvm-svn: 279746
2016-08-25 15:56:55 +00:00
Marshall Clow d437fa5c8c Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these functions everywhere instead of assert()ing when exceptions are disabled. WARNING: This is a behavior change - but only with exceptions disabled. Reviewed as: https://reviews.llvm.org/D23855.
llvm-svn: 279744
2016-08-25 15:09:01 +00:00
Aditya Kumar 331fb804c9 Remove trailing WS [NFC]
llvm-svn: 279731
2016-08-25 11:52:38 +00:00
Chris Bieneman f17227a1da [CMake] Be more consistent about naming targets and components
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
2016-08-24 22:17:06 +00:00
Saleem Abdulrasool e81fcb81dc libc++: add an option to build against compiler-rt
This mirrors the option in libc++abi to build without libgcc.

llvm-svn: 279606
2016-08-24 04:22:52 +00:00
Saleem Abdulrasool 7fe0681e28 Revert "libc++: Perform configuration checks with -nodefaultlibs"
This reverts SVN r279584 which broke the buildbots.  Will re-apply once the
issue has been root-caused and fixed.

llvm-svn: 279596
2016-08-24 00:24:05 +00:00
Saleem Abdulrasool 12a0b1f4c8 libc++: Perform configuration checks with -nodefaultlibs
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
2016-08-23 23:01:16 +00:00
Adhemerval Zanella 9704d235d0 libcxx: Fix libcxx tests on aarch64 with libunwind
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
2016-08-23 19:25:12 +00:00
Marshall Clow 3820ac3106 Add missing include that caused a test failure on Windows. Thanks to STL for the patch. No functional change.
llvm-svn: 279453
2016-08-22 18:45:31 +00:00
Chris Bieneman 12b134bd4b [CMake] Get libcxx building under LLVM/runtimes
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
2016-08-18 21:31:51 +00:00
Marshall Clow d4e8659dfc make the associative containers do the right thing for propogate_on_container_assignment. Fixes bug #29001. Tests are only for <map> right now - more complete tests will come when we revamp our allocator testing structure.
llvm-svn: 279008
2016-08-17 23:24:02 +00:00
Marshall Clow 2a10c960fa Support allocators with explicit conversion constructors. Fixes bug #29000
llvm-svn: 278904
2016-08-17 05:58:40 +00:00