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

C++11. I'm not sure that this is a good idea, but I know some crazy
folks on the core working group who like to live dangerously, and they
should still be able to build LLD. =D

llvm-svn: 202568

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

When lowering a bitfield, CGRecordLowering would assign the wrong 
storage type to a bitfield in some cases and trigger an assertion.  In 
these cases the layout was still correct, just the bitfield info was 
wrong.

llvm-svn: 202562

<rdar://problem/15949113>

llvm-svn: 202561

it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.

With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).

llvm-svn: 202560