| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Merge vrshr_n_v and vqshlu_n_v with ARM.
Remove FIXME comments for others as they can't actually be shared.
NFC.
Differential Revision: http://reviews.llvm.org/D4697
llvm-svn: 214173
|
| |
|
|
|
|
| |
parameter from method classof().
llvm-svn: 214172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This broke the following gdb tests:
gdb.base__annota1.exp
gdb.base__consecutive.exp
gdb.python__py-symtab.exp
gdb.reverse__consecutive-precsave.exp
gdb.reverse__consecutive-reverse.exp
I will look into this.
This reverts commit 214162.
llvm-svn: 214163
|
| |
|
|
|
|
|
|
|
| |
This allows us to give more precise diagnostics.
Diego kindly tested the impact on debug info size: "The increase on average
debug sizes is 0.1%. The total file size increase is ~0%."
llvm-svn: 214162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The -mstrict-align option was originally added in r167619 as a target-
independent option. It was then changed in r167623 to be implemented with an
ARM-specific backend option, even though the code remained in the
target-independent Clang::ConstructJob function. This means that if you used
the -mstrict-align option with a non-ARM target, you would still get the
-arm-strict-align option getting passed to the backend, which was harmless
but gross. The driver option was then replaced by the GCC-compatible
-m[no-]unaligned-access option (r189175) and modified to work with AArch64
(r208075). However, in the process, the help text for -mstrict-align was
incorrectly changed to show it as only being supported for AArch64. Even worse,
the logic for handling these options together with -mkernel was wrong for
AArch64, where -mkernel does not currently imply strict alignment.
This patch fixes up all of those things. Besides the obvious change to the
option help text, it moves the logic into the ARM and AArch64-specific parts
of the driver, so that the option will be correctly ignored for non-ARM
targets. <rdar://problem/17823697>
llvm-svn: 214148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't nearly as elaborate as the GCC inline asm which emits an
array of source locations, but it's very, very hard to trigger backend
diagnostics in MS inline asm because we parse it up front with good
source information, unlike GCC inline asm.
Currently I can trigger a "inline assembly requires more registers than
available" diagnostic with this code:
void foo();
void bar() {
__asm pusha
__asm call foo
__asm popa
}
However, if I committed that as a test case, I would have to remove it
once I fix PR20052.
llvm-svn: 214141
|
| |
|
|
|
|
|
| |
This is the last patch to unique the type array of a subroutine type.
This is the paired commit with llvm r214132.
llvm-svn: 214133
|
| |
|
|
| |
llvm-svn: 214124
|
| |
|
|
|
|
|
|
|
|
| |
char-based types from "char" to "signed char". Adjust stdint.h to use
__INTx_TYPE__ directly without prefixing it with signed and to use
__UINTx_TYPE__ for unsigned ones.
The value of __INTx_TYPE__ now matches GCC.
llvm-svn: 214119
|
| |
|
|
|
|
| |
This is the paired commit with llvm r214112.
llvm-svn: 214113
|
| |
|
|
|
|
|
|
|
|
| |
The new flag, WantFunctionLikeCasts, covers a subset of the keywords
covered by WantTypeSpecifiers that can be used in casts that look like
function calls, e.g. "return long(5);", while excluding the keywords
like "enum" and "const" that would be included when WantTypeSpecifiers
is true but cannot be used in something that looks like a function call.
llvm-svn: 214109
|
| |
|
|
|
|
| |
Part of <rdar://problem/17688758>
llvm-svn: 214099
|
| |
|
|
|
|
| |
Part of <rdar://problem/17688758>
llvm-svn: 214098
|
| |
|
|
|
|
|
|
|
| |
There is no functional change here.
The idea is to have a similar order and categories of functions that we have
in avxintrin.h.
llvm-svn: 214097
|
| |
|
|
| |
llvm-svn: 214096
|
| |
|
|
|
|
|
|
| |
til::SExpr. This is a large patch, with many small changes to pretty printing
and expression lowering to make the new SExpr representation equivalent in
functionality to the old.
llvm-svn: 214089
|
| |
|
|
|
|
| |
Initial patch and tests by Kaushik Sridharan, thank you!
llvm-svn: 214084
|
| |
|
|
|
|
|
|
|
|
| |
Before:
static_assert(is_convertible < A &&, B > ::value, "AAA");
After:
static_assert(is_convertible<A &&, B>::value, "AAA");
llvm-svn: 214075
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
llvm-svn: 214074
|
| |
|
|
|
|
|
|
|
|
| |
Before (with left pointer alignment):
void f(int i = 0, SomeType* *temps = NULL);
After:
void f(int i = 0, SomeType** temps = NULL);
llvm-svn: 214071
|
| |
|
|
|
|
|
|
|
|
| |
Before:
int x = ~ * p;
After:
int x = ~*p;
llvm-svn: 214070
|
| |
|
|
|
|
|
|
|
|
| |
Before:
SomeFunction([](int i)LOCKS_EXCLUDED(a) {});
After:
SomeFunction([](int i) LOCKS_EXCLUDED(a) {});
llvm-svn: 214069
|
| |
|
|
| |
llvm-svn: 214064
|
| |
|
|
| |
llvm-svn: 214060
|
| |
|
|
| |
llvm-svn: 214059
|
| |
|
|
| |
llvm-svn: 214051
|
| |
|
|
|
|
|
|
|
|
| |
lambda expressions (other than their capture initializers) nor blocks. Do walk
into default argument expressions and default initializer expressions.
These bugs were causing us to produce broken CFGs whenever a lambda expression
was used to initialize a libstdc++ std::function object!
llvm-svn: 214050
|
| |
|
|
|
|
| |
from a .def file or similar...
llvm-svn: 214049
|
| |
|
|
|
|
| |
record type in LLVM's IR module.
llvm-svn: 214048
|
| |
|
|
| |
llvm-svn: 214047
|
| |
|
|
| |
llvm-svn: 214038
|
| |
|
|
| |
llvm-svn: 214036
|
| |
|
|
|
|
|
|
| |
properties are not synthesized in property auto-synthesis,
as it can potentiall lead to runtime errors.
rdar://17774815
llvm-svn: 214032
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add abbreviation for CXXMethodDecl and for FunctionProtoType. These come up
a *lot* in C++ modules.
* Allow typedef declarations to use the abbreviation if they're class members,
or if they're used.
In passing, add more record name records for Clang AST node kinds.
The downside is that we had already used up our allotment of 12 abbreviations,
so this pushes us to an extra bit on each record to support the extra abbrev
kinds, which increases file size by ~1%. This patch *barely* pays for that
through the other improvements, but we've got room for another 18 abbrevs,
so we should be able to make it much more profitable with future changes.
llvm-svn: 214024
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parser::ParseDeclarationSpecifiers eagerly updates the source range of
the DeclSpec with the current token position. However, it might not
consume any more tokens.
Fix this by only setting the start of the range, not the end. This way
the SourceRange will be invalid if we don't consume any more tokens.
This fixes PR20413.
Differential Revision: http://reviews.llvm.org/D4646
llvm-svn: 214018
|
| |
|
|
|
|
| |
if the two arguments are equal.
llvm-svn: 214008
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This moves some memptr specific code into the generic thunk emission
codepath.
Fixes PR20053.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D4613
llvm-svn: 214004
|
| |
|
|
| |
llvm-svn: 214003
|
| |
|
|
|
|
|
| |
This isn't a real diagnostic kind, only a location note, and this form isn't even
used if the SourceManager can provide a valid presumed location. But still.
llvm-svn: 214002
|
| |
|
|
| |
llvm-svn: 213999
|
| |
|
|
|
|
| |
each different enum value here.
llvm-svn: 213996
|
| |
|
|
|
|
|
|
|
| |
llvm revision 210639 renamed the -global-merge backend option to
-enable-global-merge. This change simply updates clang to match that.
Patch by Steven Wu!
llvm-svn: 213993
|
| |
|
|
|
|
|
|
|
| |
Previously we were building up the inalloca struct in the usual pattern
of return type followed by arguments. However, on Windows, 'this'
always precedes the 'sret' parameter, so we need to insert it into the
struct first as a special case.
llvm-svn: 213990
|
| |
|
|
|
|
|
|
| |
The target method of the thunk will perform the cleanup. This can't be
tested in 32-bit x86 yet because passing something by value would create
an inalloca, and we refuse to generate broken code for that.
llvm-svn: 213976
|
| |
|
|
|
|
| |
for NetBSD.
llvm-svn: 213972
|
| |
|
|
|
|
|
| |
We no longer plan to use __except_hander3 and rather use custom
personality functions per __try block.
llvm-svn: 213971
|
| |
|
|
|
|
|
| |
expression is a forward declaration as this results
in undefined behavior. rdar://17768630
llvm-svn: 213968
|
| |
|
|
|
|
| |
Patch by Stephen Drake.
llvm-svn: 213964
|
| |
|
|
|
|
|
| |
directories description. Released version of this toolchain has not separate
libraries for -mfp64 command line option.
llvm-svn: 213937
|
| |
|
|
|
|
|
|
| |
Specifically the part where we removed a warning to be compatible with GCC, which has been widely regarded as a bad idea.
I'm not quite happy with how obtuse this warning is, especially in the fairly common case of a 32-bit integer literal, so I've got another patch awaiting review that adds a fixit to reduce confusion.
llvm-svn: 213935
|