For a testcase like the following:

 typedef unsigned long uint64_t;

 typedef struct {
   uint64_t lo;
   uint64_t hi;
 } blob128_t;

 void add_128_to_128(const blob128_t *in, blob128_t *res) {
   asm ("PAND %1, %0" : "+Q"(*res) : "Q"(*in));
 }

where we'll fail to allocate the register for the output constraint,
our matching input constraint will not find a register to match,
and could try to search past the end of the current operands array.

On the idea that we'd like to attempt to keep compilation going
to find more errors in the module, change the error cases when
we're visiting inline asm IR to return immediately and avoid
trying to create a node in the DAG. This leaves us with only
a single error message per inline asm instruction, but allows us
to safely keep going in the general case.

llvm-svn: 187470

No functionality change.

llvm-svn: 187469

No functionality change.

llvm-svn: 187468

llvm-svn: 187467

Clang when linking and using a GCC installation from a GCC
cross-compiler.

This was desired already by two special case platforms (Android and
Mips), and turns out to be generally (if frustratingly) true. I've added
a substantial comment to the code clarifying the underlying assumptions
of doing actual cross compiles with Clang (or GCC for that matter!) and
help avoid further confusion here.

The end result is to realize that fully general form of PR12478 cannot
be resolved while we support existing cross-compiling GCC toolchains,
and linking with them (namely, linking against their libgcc and
libstdc++ installs). GCC installs these target libraries under
a target-specific prefix but one that may not be available within the
actual sysroot in use. When linking in this world, GCC works and Clang
should as well, but caveat emptor: DSOs from this tree must be
replicated and rpath-fixed to be found at runtime within the sysroot.

I've extended the cross compile test cases to cover these issues by
pointing them at a sysroot and actually checking the library search
paths.

llvm-svn: 187466

change, other than removal of undefined behavior.

llvm-svn: 187465

One form would accept a vector of pointers, and the other did not.
Make both accept vectors of pointers, and add an assertion
for the number of elements.

llvm-svn: 187464

The unix one was returning no_such_file_or_directory, but the windows one
was return success.

Update the one one caller that was depending on the old behavior.

llvm-svn: 187463

llvm-svn: 187462

llvm-svn: 187461

llvm-svn: 187460

llvm-svn: 187459

Before:
  template <typename... Types>
        typename enable_if < 0<sizeof...(Types)>::type Foo() {}
After:
  template <typename... Types>
  typename enable_if<0 < sizeof...(Types)>::type Foo() {}

llvm-svn: 187458

llvm-svn: 187457

llvm-svn: 187456

This avoids constant folding bitcast/ptrtoint/inttoptr combinations
that have illegal bitcasts between differently sized address spaces.

llvm-svn: 187455

Apparently dragonegg uses it.

llvm-svn: 187454

The BSS atom is similar to the regular defined atom, but it's different
in the sense that it does not have contents. Until now we assumed all the
defined atoms have its contents. That did not fit well to the BSS atom.

llvm-svn: 187453

In limited testing this seems to work. Caveat emptor.

llvm-svn: 187452

- disable some TestConcurrentEvents cases (which are affected by llvm.org/pr16714 -- watchpoints in multithreaded programs)
- relax number-of-bp-locations check in TestUniqueTypes/TestUnsignedTypes
- skip TestDataFormatterStdVector cases with GCC 4.8 (known failure due to llvm.org/pr15301)
- workaround for race condition in TestHelloWorld.py
- update TestSettings.py to work on distros (like Fedora) that have /bin/cat hardlinked to /usr/bin/cat

After these changes, the test suite should run cleanly against GCC 4.8 (with DWARF v4)!

llvm-svn: 187451

- pass through to base-class implementation when raised exception is not from an LLDBTest
- should make the test suite errors a little easier to root-cause

llvm-svn: 187450

- better than failing silently next time the DWARF standard introduces new opcodes!

llvm-svn: 187449

llvm-svn: 187448

This reverts commit 187428. It broke the windows bots.
http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/3450

llvm-svn: 187447

Debug mode for unordered_multimap.  Some mods were done for unordered_map as well to keep all the tests passing.  However unordered_map is at the very least still missing tests, if not functionality (if it isn't tested, it probably isn't working).

llvm-svn: 187446

Call into ComputeMaskedBits to figure out which bits are set on both add
operands and determine if the value is a power-of-two-or-zero or not.

llvm-svn: 187445

It will now only convert the arguments / return value and call
the underlying function if the types are able to be bitcasted.
This avoids using fp<->int conversions that would occur before.

llvm-svn: 187444

llvm-svn: 187443

llvm-svn: 187442

llvm-svn: 187441

turns "bal" into "bgezal".

llvm-svn: 187440

llvm-svn: 187439

llvm-svn: 187438

llvm-svn: 187437

When registers must be live throughout the scheduling region, increase
the limit for the register class. Once we exceed the original limit,
they will be spilled, and there's no point further reducing pressure.

This isn't a perfect heuristics but avoids a situation where the
scheduler could become trapped by trying to achieve the impossible.

llvm-svn: 187436

llvm-svn: 187435

in an expression and doesn't ignore the stop.

Patch by Jim Ingham.

<rdar://problem/14583884>

llvm-svn: 187434

register i7 as a live-in if current function's return address is taken.

This revision fixes PR16269.

llvm-svn: 187433

Both the parameter itself and the argument to the parameter must be prefixed
with -Xlinker so that they are passed properly.

llvm-svn: 187432

llvm-svn: 187431