| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 206730
|
| |
|
|
|
|
|
|
|
|
|
| |
Unlike the standard AAPCS64 ABI, variadic arguments are always passed on the
stack with the Darwin ABI, and this was not being considered when deciding
whether to expand HFA/HVA arguments in a call. An HFA argument with a "float"
base type was being expanded into separate "float" arguments, each of which
was then extended to a double, resulting in a serious mismatch from what is
expected by the va_arg implementation. <rdar://problem/15777067>
llvm-svn: 206729
|
| |
|
|
| |
llvm-svn: 206728
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It could even be made non-virtual if it weren't for bad compiler
warnings.
This demonstrates that ArgList objects aren't destroyed polymorphically
and possibly that they aren't even used polymorphically. If that's the
case, it might be possible to refactor the two ArgList types more
separately and simplify the Arg ownership model. *continues
experimenting*
llvm-svn: 206727
|
| |
|
|
| |
llvm-svn: 206726
|
| |
|
|
| |
llvm-svn: 206725
|
| |
|
|
|
|
|
|
| |
This might be able to be simplified further by using Arg as a value type
in a linked list (to maintain pointer validity), but here's something
simple to start with.
llvm-svn: 206724
|
| |
|
|
| |
llvm-svn: 206723
|
| |
|
|
| |
llvm-svn: 206722
|
| |
|
|
| |
llvm-svn: 206721
|
| |
|
|
|
|
| |
and ContextDecision in different source files (depending on #define magic).
llvm-svn: 206720
|
| |
|
|
|
|
| |
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
|