There already have two "dead" functions, initialize{IPO|IPA}, defined for 
similar purpose. I decide not to call these two functions for two reasons:
  o. they don't cover all LTO passes (which will soon be separated into IPO 
     and post-IPO passes)
  o. We have not yet figured out the right passes and the ordering for IPO 
     and post-IPO stages, meaning this change is only for the time being.

Since LTO passes are registered, we are now able to print IR before and 
after particular point.

For OSX users:
--------------
  "...-Wl,-mllvm -Wl,-print-after=<pass-name>" will print IR after the
  specified pass.

For Other UNIX with GNU gold linker:
------------------------------------
  "-Wl,-plugin-opt=-print-after=<pass-name>" should work.
  (NOTE: no need for "-Wl,-mllvm")

  Strip "-Wl," if flags are fed directly to linker instead of clang/clang++.

llvm-svn: 186853

This matches gnu archive behavior and since archive member order can change
which member is used, not changing the order on replacement looks like the
right thing to do.

This patch also refactors the logic for which archive member to keep and
whether to move it to a helper function (computeInsertAction). The
nesting in computeNewArchiveMembers was getting a bit confusing.

llvm-svn: 186829

We were incorrectly computing where to insert a member if it was replacing
a previous member that was before the insert point.

llvm-svn: 186792

The original change was rolled back in r186627 because of test
failures on the big endian machine. I believe I fixed the issue
so re-submitting.

llvm-svn: 186734

We were only handling the 'a' and 'b' options during moves before.

llvm-svn: 186721

This allows "llvm-mc -disassemble" to accept two new features:
  + Using comma as a byte separator
  + Grouping bytes with '[' and ']' pairs.

The behaviour outside a [...] group is unchanged. But within the group once
llvm-mc encounters a true error, it stops rather than trying to resynchronise
the stream at the next byte. This is more useful for disassembly tests, where
we have an almost-instruction in mind and don't care what the misaligned
interpretation would be. Particularly if it means llvm-mc won't actually see
the next intended almost-instruction.

As a side effect, this means llvm-mc can disassemble its own -show-encoding
output if copy-pasted.

llvm-svn: 186661

Because it broke s390x and ppc64-linux buildbots. This reverts commit r186623.

llvm-svn: 186627

Summary:
Dump optional data directory entries in the PE/COFF header, so that
we can test the output of LLD linker. This patch updates the test binary
file, but the source of the binary is the same. I just re-linked the file.
I don't know how the previous file was linked, but the previous file did
not have any data directory entries for some reason.

Reviewers: rafael

CC: llvm-commits

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

llvm-svn: 186623

llvm-ar: doExtract(): Write extracted files with F_Binary. It should fix llvm/test/Object/extract.ll

llvm-svn: 186503

llvm-svn: 186494

llvm-svn: 186493

This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).

llvm-svn: 186447

With this change llvm-ar can remove the temporary file on windows too.

llvm-svn: 186423

llvm-svn: 186381

This is a micro optimization. Instead of going char*->StringRef->Twine->char*,
go char*->Twine->char* and avoid having to copy the filename on the stack.

llvm-svn: 186380

Looks like on mingw we get bogus last modification times on directories.
Should fix the mingw bots.

llvm-svn: 186240

llvm-svn: 186239

original message:
Fix a off by one error about which members need to use the string table.

llvm-svn: 186238

  http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/4328

Original commit log:
  Use the function attributes to pass along the stack protector buffer
  size.

llvm-svn: 186234

  http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/6897/steps/check-all/logs/LLVM%3A%3Aarchive-format.test

Original commit log:
  Fix a off by one error about which members need to use the string
  table.

llvm-svn: 186232

Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.

llvm-svn: 186217

llvm-svn: 186216

llvm-svn: 186200

llvm-svn: 186198

This fixes two bugs is lib/Object that the use in llvm-ar found:
* In OS X created archives, the name can be padded with nulls. Strip them.
* In the constructor, remember the first non special member and use that in
  begin_children. This makes sure we skip all special members, not just the
  first one.

The change to llvm-ar itself consist of
* Using lib/Object for reading archives instead of ArchiveReader.cpp.
* Writing the modified archive directly, instead of creating an in memory
  representation.

The old Archive library was way more general than what is needed, as can
be seen by the diffstat of this patch.

Having llvm-ar using lib/Object now opens the way for creating regular symbol
tables for both native objects and bitcode files so that we can use those
archives for LTO.

llvm-svn: 186197

llvm-svn: 186170

llvm-svn: 186131

llvm-svn: 186113

llvm-svn: 186094

While at it, use strftime on Unix too and use the thread safe versions
of localtime.

llvm-svn: 186090

* It is not present on OS X.
* It is untested.
* It is not needed for using ar in a build system.

llvm-svn: 186080

llvm-svn: 186079

* All systems we support have some form of long name support.
* The options has different names and semantics in different implementations
  ('f' on gnu, 'T' on OS X), which makes it unlikely it is normally used on
  build systems.
* It was completely untested.

llvm-svn: 186078

llvm-svn: 186076

llvm-svn: 186029

The problem with running internalize before we're ready to output an object file
is that it may change a 'weak' symbol into an internal one, but that symbol
could be needed by an external object file --- e.g. with arclite.

<rdar://problem/14334895>

llvm-svn: 185882

No intended functionality change.

llvm-svn: 185832

This fixes a regression introduced by r185726: the new call to get
a unique file does not prepend the system temporary directory, so
we need to anchor on the file that the temporary file gets moved
to to ensure we're on the same file system.

llvm-svn: 185825

I wish we could typecheck llvm::format.

llvm-svn: 185766

llvm-svn: 185751