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