it interoperate (minimally) with std::unique_ptr<T>. This is part of my
plan to migrate LLVM to use std::unique_ptr with a minimal impact on
out-of-tree code.

Patch by Ahmed Charles with some minor cleanups (and bool casts) by me.

llvm-svn: 202608

llvm-svn: 202607

llvm-svn: 202606

This relies on forward declaration of enums.

llvm-svn: 202605

llvm-svn: 202604

The docs now build cleanly. Yay!

The following warnings were fixed:

/home/sean/pg/llvm/llvm/docs/HowToReleaseLLVM.rst:364: WARNING: Enumerated list ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/InAlloca.rst:: WARNING: document isn't included in any toctree

/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.

Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.

Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:185: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:565: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:567: WARNING: Block quote ends without a blank line; unexpected unindent.

llvm-svn: 202603

llvm-svn: 202602

Simple cases hit a variety of problems at -O0.

llvm-svn: 202601

This generalizes the code to eliminate extra truncs/exts around i1 bit
operations to also do the same on PPC64 for i32 bit operations. This eliminates
a fairly prevalent code wart:

int foo(int a) {
  return a == 5 ? 7 : 8;
}

On PPC64, because of the extension implied by the ABI, this would generate:

	cmplwi 0, 3, 5
	li 12, 8
	li 4, 7
	isel 3, 4, 12, 2
	rldicl 3, 3, 0, 32
	blr

where the 'rldicl 3, 3, 0, 32', the extension, is completely unnecessary. At
least for the single-BB case (which is all that the DAG combine mechanism can
handle), this unnecessary extension is no longer generated.

llvm-svn: 202600

llvm-svn: 202599

llvm-svn: 202598

llvm-svn: 202597

llvm-svn: 202596

llvm-svn: 202595

llvm-svn: 202594

llvm-svn: 202593

llvm-svn: 202592

Move prototypes into headers and fix a few inconsistencies.

llvm-svn: 202591

No functionality change.

llvm-svn: 202590

FIXME: Give appropriate \param to llvm::ArrayRef<SubmoduleID> Overrides.
llvm-svn: 202589

No intended functionality change.

llvm-svn: 202588

llvm-svn: 202587

to the build being C++11.

There is clearly still plenty of simplification than can be done here by
using standard type traits instead of rolling our own in many places.

llvm-svn: 202586

LLVM_HAS_RVALUE_REFERENCES macro.

llvm-svn: 202585

is now always 1, as we're requiring C++11 now!

llvm-svn: 202584

llvm-svn: 202583

the core LLVM libraries.

llvm-svn: 202582

llvm-svn: 202581

libraries. It is now always 1 in LLVM builds.

llvm-svn: 202580

on unconditionally. Continuing to break down the C++98 support,
hopefully without breaking anything.

llvm-svn: 202579

llvm-svn: 202578

llvm-svn: 202577

llvm-svn: 202576

llvm-svn: 202575

on the fact that we now build in C++11 mode with modern compilers. This
should flush out any issues. If the build bots are happy with this, I'll
GC all the code for coping without R-value references.

llvm-svn: 202574

llvm-svn: 202573

llvm-svn: 202572

llvm-svn: 202571

lib/Support/RWMutex.cpp contains an implementation of RWMutex that
uses pthread_rwlock, but when pthread_rwlock is not available (such as
under NaCl, when using newlib), it silently falls back to using the
no-op definition in lib/Support/Unix/RWMutex.inc, which is not
thread-safe.

Fix this case to be thread-safe by using a normal mutex.

Differential Revision: http://llvm-reviews.chandlerc.com/D2892

llvm-svn: 202570

baseline is now C++11, and we unconditionally add -std=c++11 to the
flags.

This has the dim potential to break some non-GNU-compatible compiler (in
terms of -std flags) using the makefiles, but those makefiles are
littered with GNU-style compile flags so it would be very surprising to
me for it to actually happen in practice. As always, do let me know if
there is a toolchain you're using where this doesn't work, and I'll be
watching the bots.

llvm-svn: 202569