Cleanup only.

llvm-svn: 206709

Spotted by Nick Lewycky in review, thanks!

llvm-svn: 206708

This reverts commit r206704, as expected.

llvm-svn: 206707

This reverts commit r206705, as planned.

llvm-svn: 206706

These tests fail after my BlockFrequencyInfo rewrite on two buildbots
[1][2].  I can't reproduce it locally, so I'm temporarily turning on
-debug-only=block-freq so I can find the problem.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1860
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18477

llvm-svn: 206705

This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite.

I've done a careful audit, added some asserts, and fixed a couple of
bugs (unfortunately, they were in unlikely code paths).  There's a small
chance that this will appease the failing bots [1][2].  (If so, great!)

If not, I have a follow-up commit ready that will temporarily add
-debug-only=block-freq to the two failing tests, allowing me to compare
the code path between what the failing bots and what my machines (and
the rest of the bots) are doing.  Once I've triggered those builds, I'll
revert both commits so the bots go green again.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445

<rdar://problem/14292693>

llvm-svn: 206704

This test didn't work as intended and was ultimately disabled some years ago in
r169458.

Indeed it's not clear if the '\n' was ever passed through to the driver
correctly given that lit would insert '&& {' at the newline.

Test rewritten to use printf/xargs to insert '\n' in a more reliable manner and
to use FileCheck for verification.

llvm-svn: 206703

When compiling on Linux with GCC 4.8, compilation would fail due to the use of
the offsetof macro.  This is a standard macro, defined in stddef.h.  Include
this header to ensure that offsetof is declared.

llvm-svn: 206702

There are now only a handful of Sema tests remaining that use %clang in
SemaCXX, SemaObjC and SemaTemplate.

llvm-svn: 206688

This tests for broad compatibility with platform SDK headers using the clang
driver and so belongs alongside the other header ingtegration tests.

llvm-svn: 206687

XCode 5.1.1 has shipped with fixed SDK headers.

This reverts commit r200256.

Fixes PR18322.

llvm-svn: 206686

llvm-svn: 206685

Win64 stack unwinder gets confused when execution flow "falls through" after
a call to 'noreturn' function. This fixes the "missing epilogue" problem by 
emitting a trap instruction for IR 'unreachable' on x86_x64-pc-windows.

A secondary use for it would be for anyone wanting to make double-sure that
'noreturn' functions, indeed, do not return.

llvm-svn: 206684

http://reviews.llvm.org/D3422

llvm-svn: 206683

llvm-svn: 206682

llvm-svn: 206681

When a module completes the definition of a class template specialization imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations.

llvm-svn: 206680

using preprocessor constants for printf() format
specifications.

llvm-svn: 206679

llvm-svn: 206678

This reverts commit r206666, as planned.

Still stumped on why the bots are failing.  Sanitizer bots haven't
turned anything up.  If anyone can help me debug either of the failures
(referenced in r206666) I'll owe them a beer.  (In the meantime, I'll be
auditing my patch for undefined behaviour.)

llvm-svn: 206677

llvm-svn: 206676

llvm-svn: 206675

llvm-svn: 206674

If a module doesn't meet a requirement, neither do its submodules. If we
don't propogate that, we might think it's an error to be missing a
header in one of those submodules.

llvm-svn: 206673

llvm-svn: 206672

Check whether functions have any lines associated before emitting coverage info for them. This isn't just a size/time saving, gcov may crash on these.

llvm-svn: 206671

We fseek on our output file in llvm-profdata, which errors on some
systems. Avoid getting into the situation by writing to /dev/null

llvm-svn: 206670

expressions for mov instructions instead of silently truncating by default.

For the ARM assembler, we want to avoid misleadingly allowing something
like "mov r0, <symbol>" especially when we turn it into a movw and the
expression <symbol> does not have a :lower16: or :upper16" as part of the
expression.  We don't want the behavior of silently truncating, which can be
unexpected and lead to bugs that are difficult to find since this is an easy
mistake to make.

This does change the previous behavior of llvm but actually matches an
older gnu assembler that would not allow this but print less useful errors
of like “invalid constant (0x927c0) after fixup” and “unsupported relocation on
symbol foo”.  The error for llvm is "immediate expression for mov requires
:lower16: or :upper16" with correct location information on the operand
as shown in the added test cases.

rdar://12342160

llvm-svn: 206669

llvm-svn: 206668

llvm-svn: 206667

This reverts commit r206628, reapplying r206622 (and r206626).

Two tests are failing only on buildbots [1][2]: i.e., I can't reproduce
on Darwin, and Chandler can't reproduce on Linux.  Asan and valgrind
don't tell us anything, but we're hoping the msan bot will catch it.

So, I'm applying this again to get more feedback from the bots.  I'll
leave it in long enough to trigger builds in at least the sanitizer
buildbots (it was failing for reasons unrelated to my commit last time
it was in), and hopefully a few others.... and then I expect to revert a
third time.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445

llvm-svn: 206666

This is important for symbolizing executables with debug info in
unavailable .dwo files. Even if all DIE entries are missing, we can
still symbolize an address: function name can be fetched from symbol table,
and file/line info can be fetched from line table.

llvm-svn: 206665

Unless they are in submodules that aren't available anyway, due to
requirements not being met.  Also, mark children as unavailable when the
parent is.

llvm-svn: 206664

llvm-svn: 206663

Add support for building Sphinx documentation when being built inside LLVM source tree and using CMake.

Patch by Dan Liew <daniel.liew@imperial.ac.uk>!

llvm-svn: 206662

llvm-svn: 206661

Patch by Daniel Liew <daniel.liew@imperial.ac.uk>!

llvm-svn: 206660

Both ZLIB and the debug info compressed section header ("ZLIB" + the
size of the uncompressed data) take some constant overhead so in some
cases the compressed data is actually larger than the uncompressed data.
In these cases, just don't compress or rename the section at all.

llvm-svn: 206659

Update clang to use the InstrProfReader from LLVM to read
instrumentation based profile data. This also switches us from the
naive text format to the binary format, since that's what's
implemented in the reader.

llvm-svn: 206658

llvm-svn: 206657