Refactor out new function EmitInitializerForField from EmitMemberInitializer.  The new function will be used to initialize the fields of lambda expressions.

llvm-svn: 150451

Add test cases exercising SBValue.GetObjectDescription() with the SBValue from SBTarget.FindGlobalVariables()
as well as from SBFrame.GetVariables().  Both scenarios are expected to work.

llvm-svn: 150450

llvm-svn: 150449

llvm-svn: 150447

in realloc map. 

If there is no dependency, the reallocated ptr will get garbage
collected before we know that realloc failed, which would lead us to
missing a memory leak warning.

Also added new test cases, which we can handle now.
Plus minor cleanups.

llvm-svn: 150446

for assembly instructions to occasionally come
out empty.

llvm-svn: 150445

llvm-svn: 150444

seems that sections in the memory module might be quite different from the
sections in the file module. Now we find all segments in the on disk file and
find that segment by name in the memory module and it is ok if any sections
from the file are missing in the memory image.

llvm-svn: 150443

llvm-svn: 150442

llvm-svn: 150441

expression with the original call operator, so that we don't try to
separately instantiate the call operator. Test and tweak a few more
bits for template instantiation of lambda expressions.

llvm-svn: 150440

This folds a simple loop tail into a loop latch. It covers the common (in fortran) case of postincrement loops. It's a "free" way to expose this type of loop to downstream loop optimizations that bail out on non-canonical loops (getLoopLatch is a heavily used check).

llvm-svn: 150439

llvm-svn: 150438

marking them as "live-in" into a BB ruins some invariants that the back-end
tries to maintain.

llvm-svn: 150437

llvm-svn: 150436

llvm-svn: 150435

llvm-svn: 150433

This commit contained some bugs. Revert it until I get around to fix them.

llvm-svn: 150431

llvm-svn: 150430

The scheduler will sometimes check the implicit-def list on instructions
to properly handle pre-colored DAG edges.

Also check any register mask operands for physreg clobbers.

llvm-svn: 150428

Add a test case for completion from 'settings set target.exec' to 'settings set target.exec-search-paths '.

llvm-svn: 150427

Tracking modules down when you have a UUID and a path has been improved.

DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.

Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries. 

llvm-svn: 150426

llvm-svn: 150425

(but not of) a block pointer do not cause the block pointer to
escape. This fixes rdar://10803830.

llvm-svn: 150424

Clang patch (flags) will follow shortly.
The run-time library will also follow, but not immediately.

llvm-svn: 150423

anonymous types to each other unless they have
the same byte_size.

llvm-svn: 150422

llvm-svn: 150421

constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.

llvm-svn: 150419

llvm-svn: 150418

expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:

  - Added new entry points for TreeTransform, so that we can
  explicitly establish the link between the lambda closure type in the
  template and the lambda closure type in the instantiation.
  - Added a bit into LambdaExpr specifying whether it had an explicit
  result type or not. We should have had this anyway.

This code is 'lightly' tested.

llvm-svn: 150417

v2f16 is a floating point type.  Add symbolic floating point type ranges to prevent this kind of issue in the future.

llvm-svn: 150416

llvm-svn: 150415

llvm-svn: 150414

llvm-svn: 150413

case when size is 0.

llvm-svn: 150412

llvm-svn: 150411

Diagnostic*.td files but not used in sources.

llvm-svn: 150410

llvm-svn: 150409

Don't route explicit construction via list-initialization through the functional cast code path. It sometimes does the wrong thing, produces horrible error messages, and is just unnecessary.

llvm-svn: 150408

llvm-svn: 150407