LLVM_ENABLE_ASSERTIONS instead of LIBCXX_ENABLE_ASSERTIONS when
figuring out what _DEBUG/NDEBUG defines to set. It also tries to test
the non-existent variable 'uppercase_CMAKE_BUILD_TYPE', which the top
level LLVM CMakeLists.txt sets up, but which the top level libc++
CMakeLists.txt currently does not. Changing the variable name tested
and creating the uppercase release name variable allows libc++ to
honor the LIBCXX_ENABLE_ASSERTIONS option correctly.

llvm-svn: 161308

llvm-svn: 161289

rotate is a critical algorithm because it is often used by other algorithms,
both std and non-std.  The main thrust of this optimization is a specialized
algorithm when the 'distance' to be shifted is 1 (either left or right).  To my
surprise, this 'optimization' was not effective for types like std::string.
std::string favors rotate algorithms which only use swap.  But for types like
scalars, and especially when the sequence is random access, these new
specializations are a big win.  If it is a vector<size_t> for example, the
rotate is done via a memmove and can be several times faster than the gcd
algorithm.

I'm using is_trivially_move_assignable to distinguish between types like int and
types like string.  This is obviously an ad-hoc approximation, but I haven't
found a case where it doesn't give good results.

I've used a 'static if' (with is_trivially_move_assignable) in three places. 
Testing with both -Os and -O3 showed that clang eliminated all code not be
executed by the 'static if' (including the 'static if' itself).

llvm-svn: 161247

__time_get_storage<char> to match the initialization behavior in
__time_get_storage<wchar>. Without the initialization, valgrind
reports errors in the subsequent calls to strftime_l.

llvm-svn: 161196

integers which remain unused and are subsequently leaked, so the test
fail when run under valgrind. Unless I'm overlooking a subtle reason
why they are needed I think they can be removed, allowing these tests
to pass under valgrind. The attached patch removes the variables. If
there is a reason for them to exist, I can change this to just delete
them at the end of the test.

llvm-svn: 161195

that the valgrind configuration passed to lit.py is used to run .pass
tests.

llvm-svn: 161193

localization/locale.categories/category.collate/category.ctype/locale.ctype.byname/is_1.pass.cpp
and scan_is.pass.cpp. The tests fail when the character class being
tested is compound, like ctype_base::alnum or ctype_base::graph,
because the existing series of conditionals in do_is an do_scan_is
will abort too early. For instance, if the character class being
tested is alnum, and the character is numeric, do_is will return false
because iswalpha_l will return false, 'result' becomes false, and the
'true' result from the later call to iswdigit_l ends up being ignored
. A similar problem exists in do_scan_is.

llvm-svn: 161192

std::thread::hardware_concurrency for platforms that don't offer
sysctl, but do provide a POSIX sysconf and _SC_NPROCESSORS_ONLN.

llvm-svn: 161190

test/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/pointer.pass.cpp
to accept '(nil)' as a valid representation for NULL so that the test
passes on Linux. The same thing is already done in some other tests,
like in /test/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_pointer.pass.cpp.

llvm-svn: 161188

There are a few tests that are listed as failing here for which I have
a patch in the works. I'll be sending those along soon. There are
others where I know what is going on but don't yet have a solution,
and I've included some notes for those. Several still need to be
investigated, mostly in localization and the regex test suite. I think
that many of these failures are due to locale implementation
variations that make the expected test results not match the actual
results. I'm not sure what the best way to make the tests accomodate
this sort of variation might be.

The failures in the unique_ptr test suite are very new and are caused
by a clang crash which I've not yet looked into.

llvm-svn: 161079

Despite my pathological distrust of spin locks, the number just don't lie.  I've put a small spin in __sp_mut::lock() on std::mutex::try_lock(), which is testing quite well.  In my experience, putting in a yield for every failed iteration is also a major performance booster.  This change makes one of the performance tests I was using (a highly contended one) run about 20 times faster.

llvm-svn: 160967

llvm-svn: 160959

llvm-svn: 160943

section in libc++.  This requires a recompiled dylib.  Failure to rebuild
the dylib will result in a link-time error if and only if the functions from
[util.smartptr.shared.atomic] are used.

The implementation is not lock free.  After considerable thought, I know of no
way to make the implementation lock free.  Ideas welcome along that front.  But
changing the ABI of shared_ptr is not on the table at this point.

The mutex used to lock these function is encapsulated by std::__sp_mut.  The
only thing the client knows about std::__sp_mut is that it has a void* data
member, can't be constructed, and has lock and unlock members.  Within the
binary __sp_mut is currently implemented as a pointer to a std::mutex.  That can
change in the future without disturbing the ABI (as long as sizeof(__sp_mut)
remains constant.

I specifically did not make __sp_mut a spin lock as I have a pathological
distrust of spin locks.  Testing on OS X reveals that the use of std::mutex in
this role is not a large performance penalty as long as the contention for the
mutex is low (more likely to get the lock than to have to wait).  In the future
we can still make __sp_mut a spin lock if that is what is desired (without ABI
damage).

The dylib contains 16 __sp_mut's to be chosen based on the hash of the address
of the shared_ptr.  The constant 16 is a ball-park reasonable space/time
tradeoff.

std::hash<T*> was changed to call __murmur2_or_cityhash, instead of the identity
function.  I had thought we had already done this, but I was mistaken.

All of this is under #if __has_feature(cxx_atomic) even though the
implementation is not lock free, because the signatures require access to
std::memory_order, which is currently available only under
__has_feature(cxx_atomic).

llvm-svn: 160940

llvm-svn: 160812

Patch by Andrew C. Morrow:  shims to work around macroized getc and putc on linux.  On my eglibc 2.13 based Debian system 'getc' is a macro defined in
/usr/include/stdio.h. This decision to make it a macro doesn't seem to
be guarded by any feature test macro as far as I can see.

llvm-svn: 160799

Patch by Andrew C. Morrow:  Conditionally include cxxabi.h in new.cpp and typeinfo.cpp.  Both new.cpp and typeinfo.cpp have code that is conditionally compiled
based on the LIBCXXRT and _LIBCPPABI_VERSION defines, but those files
do not currently include <cxxabi.h> in the non __APPLE__ case. The
attached patch updates those files so that for non __APPLE__ builds
<cxxabi.h> is included if available or if LIBCXXRT is set. I'm
modeling this on the recent updates to exception.cpp.

llvm-svn: 160790

<algorithm> no longer needs to include <cstdlib>, but can get away with just <cstddef>.  This was brought to my attention by Salvatore Benedetto in his port to a bare-metal coretex-m3.  This exposed two test bugs where an explicit #include <cstdlib> was needed.

llvm-svn: 160786

llvm-svn: 160785

platform-provided macro on some systems) to _LIBCPP_NORETURN.

llvm-svn: 160773

Apple LWG 2067: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3318.html#2067 .  This is the only actionable change that has been made to the C++ draft since C++11.  In general it has not been decided exactly how libc++ will track changes made to C++11.  New features and design changes will probably be #ifdef'd, especially if they are not backwards compatible.  Defects and 'dumb mistakes' are more likely to just be put in.  Decisions on telling one from the other will be made on a case by case basis.

llvm-svn: 160608

llvm-svn: 160607

llvm-svn: 160606

llvm-svn: 160605

llvm-svn: 160604

llvm-svn: 160594

llvm-svn: 160593

llvm-svn: 160592

llvm-svn: 160585

llvm-svn: 160579

llvm-svn: 160566

llvm-svn: 160565

llvm-svn: 160564

llvm-svn: 160563

llvm-svn: 160562

llvm-svn: 160510

llvm-svn: 160509

Relax the complete-type checks that are happening under __invokable<Fp, Args...> to only check Fp, and not Args... .  This should be sufficient to give the desired high quality diagnostics under both bind and function.  And this allows a test reported by Rich E on cfe-dev to pass.  Tracked by <rdar://problem/11880602>.

llvm-svn: 160285

llvm-svn: 160184

Fixed a bug in wstring_convert concerning zero-length inputs.  Thanks to Jonathan Coxhead for reporting this bug.

llvm-svn: 160136