Register coalescing can sometimes create live ranges that end in the middle of a
basic block without any killing instruction. When SplitKit detects this, it will
repair the live range by shrinking it to its uses.

Live range splitting also needs to know about this. When the range shrinks so
much that it becomes allocatable, live range splitting fails because it can't
find a good split point. It is paranoid about making progress, so an allocatable
range is considered an error.

The coalescer should really not be creating these bad live ranges. They appear
when coalescing dead copies.

llvm-svn: 130787

checking both the source and the destination operands, renaming the
warning group to -Wnon-pod-memaccess and tweaking the diagnostic text
in the process.

llvm-svn: 130786

llvm-svn: 130785

structs. // rdar://8823265

llvm-svn: 130783

Material bugfixes to come this afternoon.

llvm-svn: 130782

  - a default-on warning for pointers to dynamic classes (= classes with vtables)
  - a default-off warning for other non-POD types

llvm-svn: 130781

max(a,b) >= a -> true.  According to my super-optimizer, these are
by far the most common simplifications (of the -instsimplify kind)
that occur in the testsuite and aren't caught by -std-compile-opts.

llvm-svn: 130780

llvm-svn: 130779

llvm-svn: 130778

Modify test_image_search_paths(self) to check for the pattern "%s-[^-]*-[^-]*" % self.getArchitecture()
from the output of running 'image list -t 3' command which lists the triples of the image list.

llvm-svn: 130777

llvm-svn: 130776

llvm-svn: 130775

llvm-svn: 130774

llvm-svn: 130773

parameters on the floor in certain cases:
class X {
  template <typename T> friend typename A<T>::Foo;
};

This was parsed as a *non* template friend declaration some how, and
received an ExtWarn. Fixing the parser to actually provide the template
parameters to the freestanding declaration parse triggers the code which
specifically looks for such constructs and hard errors on them.

Along the way, this prevents us from trying to instantiate constructs
like the above inside of a outer template. This is important as loosing
the template parameters means we don't have a well formed declaration
and template instantiation will be unable to rebuild the AST. That fixes
a crash in the GCC test suite.

llvm-svn: 130772

llvm-svn: 130771

'memset' with external linkage.

llvm-svn: 130770

llvm-svn: 130769

Change one test sequence to detect the '** End Stop Hooks **' marker emitted by the
stop hooks mechanism and check for whether the 'expr ptr' stop-hook has been run.

Also, change the TestBase.tearDown() to wait for 2 seocnds before forcefully kill
the pexpect-spawned child lldb process.

llvm-svn: 130767

llvm-svn: 130766

Add a few ARM coprocessor builtins. The llvm side of the commit contains the intrinsics and matching patterns.

llvm-svn: 130765

it's possible.

llvm-svn: 130764

llvm-svn: 130763

unique_ptr and shared_ptr changes by Daniel Mierswa!

llvm-svn: 130762

llvm-svn: 130761

If the front end has emitted llvm.dbg.cu and other debug info anchors (clang does it now) then use them directly. This saves one scan of entire module, to collect debug info, which in turns saves few machine cycles at compile time.

llvm-svn: 130759

Removing strncpy() checking in CString checker for now. Some significant changes need to be made to properly support modeling of it since it potentially leaves strings non-null terminated.

llvm-svn: 130758

llvm-svn: 130757

llvm-svn: 130756

llvm-svn: 130755

llvm-svn: 130754

llvm-svn: 130753

Refactor: Move 'isParallelFor' from codegen backend to Dependences analysis, so other passes can also use it.

llvm-svn: 130752

llvm-svn: 130751

llvm-svn: 130750

llvm-svn: 130749

llvm-svn: 130748

string template.

Fixes rdar://8493866

llvm-svn: 130747

model constants which can be added to base registers via add-immediate
instructions which don't require an additional register to materialize
the immediate.

llvm-svn: 130743

to spawn an lldb child command.  The test is not "correct" in that the '** Stop Hooks **'
message emitted by the Target implementation is invoked asynchronously and is using a separate:

    CommandReturnObject result;

command return object that what the driver passes to the normal command interpreter loop.
But it can help test our output serialization work.

I need to modify the test case later to maybe only test that "-o 'expr ptr'" option does indeed work.

llvm-svn: 130742