llvm-svn: 146958

llvm-svn: 146957

llvm-svn: 146956

Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.

The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.

Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.

llvm-svn: 146955

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBValue.CreateValueFromExpression().

llvm-svn: 146954

llvm-svn: 146953

Windows subversion clients isn't setup to default to eol:native again...

llvm-svn: 146952

llvm-svn: 146951

Fixes PR11571: Instruction does not dominate all uses

llvm-svn: 146950

We used to rely on the *eh_sjlj_setjmp instructions to mark that a function
with setjmp/longjmp exception handling clobbers all the registers.  But with
the recent reorganization of ARM EH, those eh_sjlj_setjmp instructions are
expanded away earlier, before PEI can see them to determine what registers to
save and restore.  Mark the dispatchsetup instruction in the same way, since
that instruction cannot be expanded early.  This also more accurately reflects
when the registers are clobbered.

llvm-svn: 146949

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBTarget.AttachToProcessWithName() so it will not hang.

llvm-svn: 146948

llvm-svn: 146940

llvm-svn: 146939

llvm-svn: 146938

"mov r1, r2, lsl #0" should assemble as "mov r1, r2" even though it's
not strictly legal UAL syntax. It's a common extension and the friendly
thing to do.

rdar://10604663

llvm-svn: 146937

llvm-svn: 146936

llvm-svn: 146935

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBStream APIs.

llvm-svn: 146934

hitting a submodule that was never actually created, e.g., because
that header wasn't parsed. In such cases, complain (because the
module's umbrella headers don't cover everything) and fall back to
including the header.

Later, we'll add a warning at module-build time to catch all such
cases. However, this fallback is important to eliminate assertions in
the ASTWriter when this happens.

llvm-svn: 146933

merging types by name when we can.  We still don't guarantee type name linkage
but we do it when obviously the right thing to do.  This makes LTO type names 
easier to read, for example.

llvm-svn: 146932

llvm-svn: 146931

llvm-svn: 146930

fix PR11464 by preventing the linker from mapping two different struct types from the source module onto the same opaque destination type.  An opaque type can only be resolved to one thing or another after all.

llvm-svn: 146929

llvm-svn: 146928

llvm-svn: 146927

llvm-svn: 146926

e.g., "vmov.i32 d4, #-118" can be assembled as "vmvn.i32 d4, #117"

rdar://10603913

llvm-svn: 146925

llvm-svn: 146924

llvm-svn: 146923

llvm-svn: 146922

rdar://9932658

llvm-svn: 146921

llvm-svn: 146920

llvm-svn: 146919

error. // rdar://10597832

llvm-svn: 146918

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBDebugger APIs.

llvm-svn: 146917

actually requires non-trivial cleanups, so no cleanups need to be performed.

llvm-svn: 146916

llvm-svn: 146915

unpredicated. That is, turn
 subeq  r0, r1, #1
 addne  r0, r1, #1                                                                                                                                                                                                     
into
 sub    r0, r1, #1
 addne  r0, r1, #1

For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
 op    r1, ...
 str   r1, [r10]        ; end-of-life of r1 as div result
 cmp   r0, #65
 movne r1, #44  ; raw dependency on previous r1
 moveq r1, #12

If movne is unpredicated, then
 op    r1, ...
 str   r1, [r10]
 cmp   r0, #65
 mov   r1, #44  ; r1 written unconditionally
 moveq r1, #12

Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.

This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.

rdar://8951196

llvm-svn: 146914

llvm-svn: 146913

llvm-svn: 146912