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: 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: 202594

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

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

LLVM_ENABLE_CXX1Y (default *off*). =D C++98 is dead. Long live C++11.

I don't exactly recommend using C++1y just yet though...

llvm-svn: 202567

The switch has been thrown. While I'm still watching for any failures or
problems with this, the documentation can go ahead and move forward.

llvm-svn: 202566

llvm-svn: 202565

llvm-svn: 202564

[Sparc] Emit 'restore' instead of 'restore %g0, %g0, %g0'. This improves the readability of the generated code.

llvm-svn: 202563

Inside iterate, we scan backwards then scan forwards in a loop. When iteration
is not zero, the last node was just updated so we can skip it. But when
iteration is zero, we can't skip the last node.

For the testing case, fixing this will save a spill and move register copies
from hot path to cold path.

llvm-svn: 202557

Patch by Jevin Sweval!

llvm-svn: 202556

llvm-svn: 202555

Reverting until the C++11 switch is complete.

llvm-svn: 202554