| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
different source files.
llvm-svn: 206719
|
| |
|
|
|
|
| |
they need to...
llvm-svn: 206718
|
| |
|
|
|
|
|
|
|
|
| |
reason to expose a global symbol 'decodeInstruction' nor to pollute the global
scope with a bunch of external linkage entities (some of which conflict with
others elsewhere in LLVM).
This is just the initial transition to C++; more cleanups to follow.
llvm-svn: 206717
|
| |
|
|
|
|
| |
table entry for MIPS.
llvm-svn: 206716
|
| |
|
|
| |
llvm-svn: 206715
|
| |
|
|
|
|
|
|
|
| |
entirely clear whether this should be valid with modules enabled, but the fixed
code is cleaner regardless.
Also fix a TU-local type that accidentally had external linkage.
llvm-svn: 206714
|
| |
|
|
|
|
| |
Patch by Robert Matusewicz
llvm-svn: 206713
|
| |
|
|
|
|
|
|
|
| |
Implement Diagnostic::category_name() using clang_getDiagnosticCategoryText()
instead of the deprected clang_getDiagnosticCategoryName().
Preserves existing behaviour and API covered by existing tests.
llvm-svn: 206712
|
| |
|
|
|
|
| |
Patch by Robert Matusewicz
llvm-svn: 206711
|
| |
|
|
|
|
| |
Cleanup only.
llvm-svn: 206710
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
been fixed since r206644.
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
|
| |
|
|
|
|
| |
semantics wrong.
llvm-svn: 206682
|
| |
|
|
| |
llvm-svn: 206681
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
describing it.
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
|
| |
|
|
|
|
|
|
| |
source tree and using CMake.
Patch by Dan Liew <daniel.liew@imperial.ac.uk>!
llvm-svn: 206662
|
| |
|
|
| |
llvm-svn: 206661
|
| |
|
|
|
|
|
|
| |
tree and using CMake
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
|