llvm-svn: 143048

When completing "help foo bar" if "foo" is not a real command, don't ask its NULL command object to complete the line.

llvm-svn: 143047

implicitly in LookupMemberExpr and explicitly in cases where template
instantiation doesn't redo the lookup.

llvm-svn: 143046

llvm-svn: 143045

composed of one byte characters.

llvm-svn: 143044

llvm-svn: 143043

llvm-svn: 143042

llvm-svn: 143041

llvm-svn: 143040

Fixes Linux build.

llvm-svn: 143038

essence, the redeclaration chain for a class could end up in an
inconsistent state while deserializing multiple declarations in that
chain, where the circular linked list was not, in fact,
circular. Since only two redeclarations of the same entity will get
loaded when we're in this state, restore circularity when both have
been loaded. Fixes <rdar://problem/10324940> / PR11195.

llvm-svn: 143037

be set if linking against an LLVM compiled with
NDEBUG off.  If it is set, we do not enable NDEBUG
in any place where we include LLVM headers.

llvm-svn: 143036

The order of the two symbol listings in a Macho x86_64 subtractor relocation is reversed from what seems intuitive to me.

llvm-svn: 143035

llvm-svn: 143034

Include the full 64 bits of relocation data in the type info for MachO relocations, so that we can recognize scattered relocations.

llvm-svn: 143033

llvm-svn: 143032

llvm-svn: 143031

llvm-svn: 143029

true: (x *nsw x) sgt 0, where x = (y | 1).  This occurs in 464.h264ref.

llvm-svn: 143028

llvm-svn: 143027

trying to legalize the operand types when only the result type
is required to be legalized - the type legalization machinery
will get round to the operands later if they need legalizing.
There can be a point to legalizing operands in parallel with
the result: when this saves compile time or results in better
code.  There was only one case in which this was true: when
the operand is also split, so keep the logic for that bit.
As a result of this change, additional operand legalization
methods may need to be introduced to handle nodes where the
result and operand types can differ, like SIGN_EXTEND, but
the testsuite doesn't contain any tests where this is the case.
In any case, it seems better to require such methods (and die
with an assert if they doesn't exist) than to quietly produce
wrong code if we forgot to special case the node in
SplitVecRes_UnaryOp.

llvm-svn: 143026

llvm-svn: 143025

llvm-svn: 143024

Revert r142530 at least temporarily while a discussion is had on llvm-commits regarding exactly how much optsize should optimize for size over performance.

llvm-svn: 143023

llvm-svn: 143022

llvm-svn: 143021

llvm-svn: 143020

Correctly perform integral promotions on wchar_t/char16_t/char32_t in C++. <rdar://problem/10309088>.

llvm-svn: 143019

Use a worklist to prevent the iterator from becoming invalidated because of the 'removeSuccessor' call. Noticed in a Release+Asserts+Check buildbot.

llvm-svn: 143018

member expression. Refactoring to follow.

llvm-svn: 143017

instantiations too.

llvm-svn: 143016

properly marked as valid.

Also modified the "memory read" command to be able to intelligently repeat
subsequent memory requests, so now you can do:

(lldb) memory read --format hex --count 32 0x1000

Then hit enter to keep viewing the memory that follows the last valid request.

llvm-svn: 143015

llvm-svn: 143012

llvm-svn: 143011

an access specifier set on it, causing an assertion to fire when building
with a Debug+Asserts build of clang.

llvm-svn: 143010

version of the install program, which does not have the --strip-program
switch.

llvm-svn: 143009

Reported by: yabin.hwu@gmail.com

llvm-svn: 143008

llvm-svn: 143007

This code makes different decisions when compiled into x87 instructions
because of different rounding behavior.  That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).

This fixes PR11200.

llvm-svn: 143006

llvm-svn: 143005