Refactor the header to allow us to implement alternate threading models
with alternate data structures.  Take the opportunity to clang-format
the area.  This will allow us to avoid re-declaring the interfaces for
Win32 threading.  NFC

llvm-svn: 290850

This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:

1) It forgot to teach the test suite about "default" ABI libraries.

2) Some LLVM builders don't clear the CMake cache between builds. The previous
   patch caused those builders to fail since their old cache entry for
   LIBCXX_CXX_ABI="" is no longer valid.

The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.

Original commit message
-----------------------

Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).

The main changes in this patch are:

1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.

Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.

llvm-svn: 290849

llvm-svn: 290848

llvm-svn: 290847

This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.

llvm-svn: 290846

llvm-svn: 290845

llvm-svn: 290844

llvm-svn: 290843

In many translation units I have tried, the calls to isIgnored() removed
in this patch are more expensive than doing the analysis that is behind
it. The speed-up in translation units I have tried is between 10 and
20%.

Review: https://reviews.llvm.org/D28208
llvm-svn: 290842

llvm-svn: 290841

Currently libc++ compiles a special version of error_category()
into the dylib. This definition is no longer needed, and doesn't
work on Windows due to dllimport/dllexport semantics.

For those reasons this patch introduces an option to
disable/enable this definition. By default the definition
is provided in ABI v1 except on windows. This patch
also addresses D28210.

llvm-svn: 290840

Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).

The main changes in this patch are:

1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.

Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.

llvm-svn: 290839

Summary:
The documentation assumed expertise with FileCheck; many clang-tidy check
authors may not have significant exposure to FileCheck, and so it's worth
spending a few more words here to spell things out.

Reviewers: alexfh

Subscribers: cfe-commits, JDevlieghere

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

llvm-svn: 290838

Move the windows specific macro definitions for compiling c++ into the
target.  Add a number of newer options that are necessary to properly
build libc++ for windows.  This ensures that we do not accidentally
autolink msvcprt (Microsoft's C++ runtime library), do not define linker
pragmas which are msvcprt specific, and do not accidentally encode the
incorrect version of the msvc compatibility version.

llvm-svn: 290837

Disable the manifest bundling on Windows when cross-compiling on
not-Windows.  With this, it is possible to execute the link command from
CMake which will use cmake to invoke the manifest tool to generate a
manifest and pass that to the linker.

llvm-svn: 290836

The locale structures have been made opaque in CRT 14+.  This currently
prevents building libc++ for Windows.  We can re-enable this in the
future when we have replicated the structure to access the private field
for the name (unless there exists a better supported mechanism to query
the name of a locale given the locale_t).

llvm-svn: 290835

This should allow us to avoid most order dependence in the runtime library configurations.

llvm-svn: 290834

Summary:
Regardless how the loop body weight is distributed, we should preserve
total loop body weight. i.e. we should have same weight reaching the body of the loop
or its duplicates in peeled and unpeeled case.

Reviewers: mkuper, davidxl, anemet

Subscribers: llvm-commits

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

llvm-svn: 290833

Attempts to fix Windows build breakage caused by r290818.

llvm-svn: 290832

In the previous fix I used a PMF type as a semi-safe bool type in C++03.
However immediately after committing I realized clang offered explicit
conversion operators as an extension. This patch removes the old fix and
enables _LIBCPP_EXPLICIT using __has_extension instead.

This change also affects the following other classes, which have
'_LIBCPP_EXPLICIT operator bool()'.

* shared_ptr
* unique_ptr
* error_condition
* basic_ios
* function (already C++11 only)
* istream::sentry
* experimental::string_view.

In all of the above cases I believe it is safe to enable the extension, except
in the experimental::string_view case. There seem to be some Clang bugs
affecting the experimental::string_view conversion to std::basic_string. To
work around that I manually disabled _LIBCPP_EXPLICIT in that case.

llvm-svn: 290831

llvm-svn: 290830

llvm-svn: 290829

llvm-svn: 290828

llvm-svn: 290827

The checks were improved with:
https://reviews.llvm.org/rL290194

llvm-svn: 290826

It placates some bots which complain because they compile the
assertion out and think the variable is unused.

llvm-svn: 290825

As pointed out by Howard, this is actually 134774 days (* 24 * 3600),
and therefore seconds, not 100ns units.  Adjust the units to reflect
reality.

llvm-svn: 290824

Visual C++ 14 and newer split msvcrt into msvcrt and ucrt with flavours
of the ucrt for different environments.  This changed the access to the
ctype table by introducing the `__pctype_func` and `__pwctype_func`
accessors.  Use this rather than directly accessing `_ctype` which
allows us to be safer in threaded situations by going through the libc
locking.

llvm-svn: 290823

Apparently my suggestion of using ternary doesn't really work
as clang complains about incompatible types on LHS and RHS. Some
GCC versions happen to accept the code but clang behaviour is
correct here.

llvm-svn: 290822

TestNoreturnUnwind fails on arm/aarch32 linux targets.

Bug is already described for x86_64 android targets in llvm.org/pr31192.

llvm-svn: 290821

llvm-svn: 290820

Split the PDB tests into DWARF test and actual PDB tests, the latter
requiring DIA SDK. Use the new LLVMConfig.cmake LLVM_ENABLE_DIA_SDK
symbol to enable the PDB tests rather than relying on
llvm/Config/config.h private include file that is not available when
building standalone.

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

llvm-svn: 290819

Add an explicit LLVM_ENABLE_DIA_SDK option to control building support
for DIA SDK-based debugging. Control its value to match whether DIA SDK
support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB).

Its value is needed for LLDB to determine whether to run tests requiring
DIA support. Currently it is obtained from llvm/Config/config.h;
however, this file is not available for standalone builds. Following
this change, LLDB will be modified to use the value from LLVMConfig.

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

llvm-svn: 290818

GNU as rejects input where .cfi_sections is used after .cfi_startproc,
if the new section differs from the old. Adjust our output to always
emit .cfi_sections before the first .cfi_startproc to minimize necessary
code.

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

llvm-svn: 290817

NewGVN: Add UnknownExpression and create them for things we can't symbolize. Kill fragile machinery for handling null expressions.

Summary:
This avoids the very fragile code for null expressions. We could also use a denseset that tracks which things have null expressions instead, but that seems pretty fragile and premature optimization.

This resolves a number of infinite loop cases, test reductions coming.

Reviewers: davide

Subscribers: llvm-commits

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

llvm-svn: 290816

Summary: Previously, we tried to fix up the equivalences during symbolic evaluation.  This does not work. Now, we change the equivalences during congruence finding, where it belongs.  We also initialize the equivalence table to give a maximal answer.

Reviewers: davide

Subscribers: llvm-commits

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

llvm-svn: 290815

The pass has been on by default for a long time without problems.

llvm-svn: 290814

[OpenMP] Add test cases for the proc_bind and schedule clauses with 'teams distribute parallel for' pragma.

https://reviews.llvm.org/D28205

llvm-svn: 290813

(This changed was approved in https://reviews.llvm.org/D28118, but Simon asked to submit it separately).

llvm-svn: 290812

Revert "DR1391: Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation."

This reverts commit r290808, as it broken all ARM and AArch64 test-suite
test: MultiSource/UnitTests/C++11/frame_layout

Also, please, next time, try to write a commit message in according to
our guidelines:

http://llvm.org/docs/DeveloperPolicy.html#commit-messages

llvm-svn: 290811