that breaks on big-endian machines.

I have to clean up the 32/64 bit confusion in libDebugInfo some day.

llvm-svn: 143812

llvm-svn: 143811

llvm-svn: 143810

Add an option to pad an uleb128 to MCObjectWriter and remove the uleb128 encoding from the DWARF asm printer.

As a side effect we now print dwarf ulebs with .ascii directives.

llvm-svn: 143809

llvm-svn: 143808

it the exact same way that the Clang code computes this path.

Hopefully with this, the MSVC bots will actually come back to life.

llvm-svn: 143807

builtin headers are no longer going to receive the old 'implicit extern
"C" block' semantics. This hint is actually ignored by both Clang and
GCC at this point, and Clang's own builtin headers can simply be changed
if there is any issue with this. Clang should be free to include these
however it wants, and so shorter and simpler is better.

Note: *nothing* is changing about the *system* stddef.h include. That
should always have the exact same include semantics, whether with Clang
or GCC or any other compiler. Only the compiler-builtin header search
path is changing.

If anyone knows of some risk that this introduces that I've not thought
of, please chime in. So far, only Windows has switched to the Brave New
World, but others should be switching soon.

llvm-svn: 143806

to do "realistic" includes, and so need the header search logic now in
the driver. This in turn requires switching the CC1 options to the
actual driver options, and passing -Xclang where there is no analogy.

llvm-svn: 143805

is a pretty gross hack, but I don't have any significantly cleaner ideas
for this. There are several things obviously gross about it:

1) Lit shouldn't know that Clang needs this. This really that bad, as
   Lit already knows about CC1 and other internal details.
2) This hard codes the '3.0' version number, which is pretty lame.
3) This hard codes every other aspect of the resource dir structure
   which is less lame than the version number, but still not great.

However, it should bring the MSVC tests back to life, and it should
unblock the rest of the move from Frontend to Driver, so I think it's
worth a bit of grossness that is isolated in our testing infrastructure
while we figure out the best long term approach. I have the following
ideas, some of which only solve part of the problem (and thus might need
to be combined with other ideas):

a) Create a symlink or other convenience path instead of a version
   number.
b) Run 'clang' directly in the lit.cfg, look at its resource dir, and use
   that.
c) Switch all the tests to use the driver instead of CC1.
d) Hack the frontend to synthesize builtin include directories when none
   are provided by the driver.

I don't like (d) because it feels very hackish and likely to break. We
can only solve a small part of the problem with (a). I wanted to vote
for (c), but lots of the tests in this bucket are really heavily using
internal-only flags like -verify and -triple. I'm loath to complicate
them with the full driver layer. Also, switching them to the driver adds
more than just builtin headers, but all of the rest of the system
headers!

This leaves me with (b). If others like (b), I'll switch to it, but it
felt a bit icky. Nothing concrete, and the other options look
significantly worse, but I felt icky enough that I wanted to start with
a more brain-dead patch to stop the bleeding, and gauge others' feelings
here.

llvm-svn: 143804

llvm-svn: 143803

llvm-svn: 143802

actually manage the builtin header file includes as well as the system
ones.

This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.

Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.

Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.

llvm-svn: 143801

llvm-svn: 143800

llvm-svn: 143799

encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.

There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.

Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.

llvm-svn: 143798

Tweak LookThroughStmt() in LiveVariables to properly look through alternativing ParenExprs and OpaqueValueExprs.  Thanks to Anna and Argiris for iterating on this function.  My original patch embarssingly didn't even pass the Clang tests.

llvm-svn: 143797

llvm-svn: 143796

llvm-svn: 143795

llvm-svn: 143794

 - Generates the llvm-config-2 LibraryDependencies.inc file.
 - Generates dependency information so that cmake will automatically reconfigure
   when LLVMBuild.txt files are changed.

llvm-svn: 143793

llvm-svn: 143792

to go through the driver.

llvm-svn: 143791

Make test/Analysis/misc-ps.c test pass.

llvm-svn: 143790

Until we find out a way to easily find out what changed by looking at the logs.

llvm-svn: 143789

llvm-svn: 143788

llvm-svn: 143787

llvm-svn: 143786

other aspects of the gold plugin docs to reflect reality.

llvm-svn: 143785

materialise them in LTO.

I observed a ~0.5-1% speedup for an LTO link of opt.

llvm-svn: 143784

(Ninja generator requirement.)

llvm-svn: 143783

llvm-svn: 143782

llvm-svn: 143781

switch statement, not the while loop).

llvm-svn: 143780

llvm-svn: 143779

llvm-svn: 143778

llvm-svn: 143777

llvm-svn: 143776

llvm-svn: 143775

llvm-svn: 143774

llvm-svn: 143773