Fix two issues I found while writing these tests.

llvm-svn: 189341

an allocation that is greater than what we will actually allocate.

Patch by Artyom Skrobov!

llvm-svn: 189340

llvm-svn: 189339

llvm-svn: 189338

Previously builder-type calls were only correctly recognized in
top-level calls.

This fixes llvm.org/PR16981.
Before:
  someobj->Add((new util::filetools::Handler(dir))->OnEvent1(
      NewPermanentCallback(this, &HandlerHolderClass::EventHandlerCBA))
                   ->OnEvent2(NewPermanentCallback(
                                  this, &HandlerHolderClass::EventHandlerCBB))
                   ->OnEvent3(NewPermanentCallback(
                                  this, &HandlerHolderClass::EventHandlerCBC))
                   ->OnEvent5(NewPermanentCallback(
                                  this, &HandlerHolderClass::EventHandlerCBD))
                   ->OnEvent6(NewPermanentCallback(
                         this, &HandlerHolderClass::EventHandlerCBE)));

After:
  someobj->Add((new util::filetools::Handler(dir))
                   ->OnEvent1(NewPermanentCallback(
                         this, &HandlerHolderClass::EventHandlerCBA))
                   ->OnEvent2(NewPermanentCallback(
                         this, &HandlerHolderClass::EventHandlerCBB))
                   ->OnEvent3(NewPermanentCallback(
                         this, &HandlerHolderClass::EventHandlerCBC))
                   ->OnEvent5(NewPermanentCallback(
                         this, &HandlerHolderClass::EventHandlerCBD))
                   ->OnEvent6(NewPermanentCallback(
                         this, &HandlerHolderClass::EventHandlerCBE)));

llvm-svn: 189337

llvm-svn: 189336

These instructions aren't particularly complicated and it's well worth having
patterns for some reasonably useful LLVM IR that will match them. Soon we
should be able to switch Clang over to producing this natural version.

llvm-svn: 189335

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 189334

[mips][msa] Added tests for and.v, bmnz.v, bmz.v, bsel.v, nor.v, or.v, xor.v when non-byte vectors are used.

Note that all of these tests use ld.b and st.b for the loads and stores
regardless of the data size. This is because the definition of bitcast is
equivalent to a store/load sequence and DAG combiner accordingly folds bitcasts
to/from v16i8 into the load/store nodes to product load/store nodes with
type v16i8.

llvm-svn: 189333

llvm-svn: 189332

Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs.
Lengths above that threshold use a loop to handle X*256 bytes followed
by a single MVC to handle the excess (if any).  This loop will also be
needed in future when support for variable lengths is added.

Because the same tablegen classes are used to define MVC and CLC,
the patch also has the side-effect of defining a pseudo loop instruction
for CLC.  That instruction isn't used yet (and wouldn't be handled correctly
if it were).  I'm planning to use it soon though.

llvm-svn: 189331

llvm-svn: 189330

Summary:
1) Make llvm-symbolizer properly symbolize
files with split debug info (by using stanalone .dwo files).
2) Make DWARFCompileUnit parse and store corresponding .dwo file,
if necessary.
3) Make bits of DWARF parsing more CompileUnit-oriented.

Reviewers: echristo

Reviewed By: echristo

CC: bkramer, llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1164

llvm-svn: 189329

Before (with 60 character limit in Google style):
  return {
      {aaaaaaaaaaaaaaaaaaaaaaaaa}, {aaaaaaaaaaaaaaaaa},
      {aaaaaaaaaaaaaaaaaaaaaaaaa}, {aaaaaaaaaaaaaaaaa}};
After:
  return {{aaaaaaaaaaaaaaaaaaaaaaaaa}, {aaaaaaaaaaaaaaaaa},
          {aaaaaaaaaaaaaaaaaaaaaaaaa}, {aaaaaaaaaaaaaaaaa}};

llvm-svn: 189327

llvm-svn: 189326

TemplateExpansion cannot happen here because MSVC doesn't mangle
anything but the fully substituted template arguments.

llvm-svn: 189325

Thanks to Luca Falavigna for the help and most of the patch.

llvm-svn: 189324

More fallout from my mass-Mach-O-renaming.

llvm-svn: 189323

Revert "Fix the build broken by r189315." and "Move everything depending on Object/MachOFormat.h over to Support/MachO.h."

This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.

llvm-svn: 189321

This was added in r166676 based on PR13942 on the basis that tools may
need debug information for any executable code/function for some fairly
broad/non-specific purposes. It seems to me (as noted in PR14569) that
the major/only purpose is in backtraces, which should generally not
apply to thunks as they won't appear in the stack themselves. By
removing them we fix PR14569 and reduce the size of Clang's debug info.

Strangely enough this doesn't seem to have a substantial impact on
Clang's self-hosted debug info (at least looking at DWO file size) size
at all. Not sure if I failed to test this correctly but I only observed
a 0.004% change in DWO file size over Clang+LLVM.

With thanks to Dinesh Dwivedi for work on this PR.

llvm-svn: 189320

(this triggered Clang's -Wsometimes-uninitialized on the default path
through the switch)

llvm-svn: 189319

Differential Revision: http://llvm-reviews.chandlerc.com/D1527

llvm-svn: 189318

llvm-svn: 189317

Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix
LLDB to use the new names. While I was here, I decided that a COFF
plugin really shouldn't be using Mach-O enums.

llvm-svn: 189316

llvm-svn: 189315

Right now we have two headers for the Mach-O format. I'd like to get rid
of one. Since the other object formats are all in Support, I chose to
keep the Mach-O header in Support, and discard the other one.

llvm-svn: 189314

should not split up that pathname itself or require quoting to avoid the same.

This fixing a bug where target create -c "core file" or target create -s "symbol file"
will fail with an error message that the paths haven't been properly quoted.  Working
around it required target create -c "core\ file" to survive both attemps at tokenizing.

<rdar://problem/14230629> 

llvm-svn: 189313

Noticed by Stephen Checkoway <s@pahtak.org>.

llvm-svn: 189312

Patch by Edoardo P. <ed0.88.prez@gmail.com>.

llvm-svn: 189311

llvm-svn: 189310

The code offset for unwind code SET_FPREG is wrong because it is set
to constant 0. The fix is to do the same as for the other unwind
codes: emit a label and later the absolute difference between the
label and the begin of the prologue.
Also enables the failing test case MC/COFF/seh.s

Reviewed by Jim Grosbach, Charles Davis and Nico Rieck.

llvm-svn: 189309

llvm-svn: 189308

With this patch the entry symbol is treated as an undefined symbol, to force
the resolver to resolve the entry symbol.

Differential Revision: http://llvm-reviews.chandlerc.com/D1524

llvm-svn: 189307

llvm-svn: 189306

out of a binary, if the Mach-O binary is MH_PRELOAD ("standalone"), don't
let the OS be set to "ios" or "macosx" - there will be no dynamic loader
used when debugging this process.
<rdar://problem/9956443> 

llvm-svn: 189305

This sets flags and excludes things that aren't working with MSVC yet,
allowing us to build the ASan runtime as part of the cmake build.

Differential Revision: http://llvm-reviews.chandlerc.com/D1525

llvm-svn: 189304

latest draft of the ABI.

llvm-svn: 189303

llvm-svn: 189302

llvm-svn: 189301

off of the debug_info section even when split dwarf is enabled.

llvm-svn: 189300