| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 253350
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r253269.
This leads to assert / segfault triggering on the following reduced example:
float foo(float U, float base, float cell) { return (U = 2 * base) - cell; }
llvm-svn: 253337
|
| |
|
|
|
|
| |
diagnostics. NFC
llvm-svn: 253316
|
| |
|
|
| |
llvm-svn: 253315
|
| |
|
|
| |
llvm-svn: 253314
|
| |
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
| |
|
|
|
|
| |
Differential Revision: D14200
llvm-svn: 253269
|
| |
|
|
|
|
|
| |
It could be derived from gnutools::Linker directly but this way makes it
consistent with all the other toolchains around it.
llvm-svn: 253259
|
| |
|
|
|
|
|
|
| |
peephole I added in r250916.
rdar://23559789
llvm-svn: 253255
|
| |
|
|
|
|
|
|
|
|
| |
target attribute, don't include "negative" subtarget features in the
list of required features. Builtins are positive by default so don't
need this change, but we pull the default list of features from the
command line and so need to make sure that we only include features
that are turned on for code generation in our error.
llvm-svn: 253242
|
| |
|
|
|
|
|
| |
Instead, use the constant "mips" since the libraries are already
placed under the multilib's OS suffix.
llvm-svn: 253214
|
| |
|
|
| |
llvm-svn: 253213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two intrinsics are defined in arm_acle.h.
__rev16l needs to rotate by 16 bits, bit it was actually rotating by 2 bits.
For AArch64, where long is 64 bits, this would still be wrong.
__rev16ll was incorrect, it reversed the bytes in each 32-bit word, rather than
each 16-bit halfword. The correct implementation is to apply __rev16 to the top
and bottom words of the 64-bit value.
For AArch32 targets, these get compiled down to the hardware rev16 instruction
at -O1 and above. For AArch64 targets, the 64-bit ones get compiled to two
32-bit rev16 instructions, because there is not currently a pattern for the
64-bit rev16 instruction.
Differential Revision: http://reviews.llvm.org/D14609
llvm-svn: 253211
|
| |
|
|
|
|
|
|
|
| |
This has seen quite some usage and I am not aware of any issues. Also
add a style option to enable/disable include sorting. The existing
command line flag can from now on be used to override whatever is set
in the style.
llvm-svn: 253202
|
| |
|
|
|
|
|
|
| |
The TargetParser API to get the default FPU and default extensions has
changed so that it can fall back to the architecture in case of a
generic CPU.
llvm-svn: 253199
|
| |
|
|
| |
llvm-svn: 253191
|
| |
|
|
|
|
|
|
|
|
| |
In r253186, I changed the DIBuilder API to now take size and align
for reference types as well. This was done in preparation for upcoming
changes to the Verifier that will validate that sizes match between
DI types and IR values that are declared as having those types.
This updates clang to actually pass the information through.
llvm-svn: 253190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_empty, is_polymorphic, and is_abstract didn't handle incomplete types
correctly. Only non-union class types must be complete for these
traits.
is_final and is_sealed don't care about the particular spelling of the
FinalAttr.
is_interface_class should always return false regardless of its input.
The type trait can only be satisfied in a mode we do not support (/CLR).
llvm-svn: 253184
|
| |
|
|
| |
llvm-svn: 253178
|
| |
|
|
|
|
|
|
|
|
| |
When calling a ObjC method on super from inside a C++ lambda, look at the
captures to find "self". This mirrors how the analyzer handles calling super in
an ObjC block and fixes an assertion failure.
rdar://problem/23550077
llvm-svn: 253176
|
| |
|
|
|
|
| |
on the AST context instead of Preprocessor. NFC
llvm-svn: 253175
|
| |
|
|
| |
llvm-svn: 253174
|
| |
|
|
| |
llvm-svn: 253173
|
| |
|
|
|
|
|
|
| |
This makes TypeAliasTemplateDecl accessible via LibClang and python bindings
Differential Revision: http://reviews.llvm.org/D13844
llvm-svn: 253166
|
| |
|
|
|
|
| |
Post-commit suggestion by Filipe Cabecinhas.
llvm-svn: 253161
|
| |
|
|
|
|
| |
DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema.
llvm-svn: 253158
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer incorrectly treats captures as references if either the original
captured variable is a reference or the variable is captured by reference.
This causes the analyzer to crash when capturing a reference type by copy
(PR24914). Fix this by refering solely to the capture field to determine when a
DeclRefExpr for a lambda capture should be treated as a reference type.
https://llvm.org/bugs/show_bug.cgi?id=24914
rdar://problem/23524412
llvm-svn: 253157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang tries to figure out if a call to abs is suspicious by looking
through implicit casts to look at the underlying, implicitly converted
type.
Interestingly, C has implicit conversions from pointer-ish types like
function to less exciting types like int. This trips up our 'abs'
checker because it doesn't know which variant of 'abs' is appropriate.
Instead, diagnose 'abs' called on function types upfront. This sort of
thing is highly suspicious and is likely indicative of a missing
pointer dereference/function call/array index operation.
This fixes PR25532.
llvm-svn: 253156
|
| |
|
|
| |
llvm-svn: 253155
|
| |
|
|
|
|
| |
ParserDiagnostic.h diagnostics.
llvm-svn: 253143
|
| |
|
|
| |
llvm-svn: 253142
|
| |
|
|
| |
llvm-svn: 253136
|
| |
|
|
| |
llvm-svn: 253135
|
| |
|
|
| |
llvm-svn: 253134
|
| |
|
|
| |
llvm-svn: 253133
|
| |
|
|
|
|
|
|
|
| |
r233345 started being stricter about typedef names for linkage purposes
in non-visible modules, but broke languages without the ODR.
rdar://23527954
llvm-svn: 253123
|
| |
|
|
|
|
|
| |
out the first missing target feature that's required and reword
the diagnostic accordingly.
llvm-svn: 253121
|
| |
|
|
| |
llvm-svn: 253119
|
| |
|
|
|
|
| |
features for calls.
llvm-svn: 253117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
VisitReturnStmt would create a new block with including Dtors, so the Dtors created
in VisitCompoundStmts would be in an unreachable block.
Example:
struct S {
~S();
};
void f()
{
S s;
return;
}
void g()
{
S s;
}
Before this patch, f has one additional unreachable block containing just the
destructor of S. With this patch, both f and g have the same blocks.
Reviewers: krememek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13973
llvm-svn: 253107
|
| |
|
|
|
|
|
|
|
| |
This reverts r243310, which is redundant as of r253102.
Conflicts:
lib/Driver/Tools.cpp
llvm-svn: 253104
|
| |
|
|
|
|
|
|
|
|
| |
When linking against text-based dynamic library SDKs the library name of a
framework has now more than one possible filename extensions. This fix tests for
both possible extensions (none, and .tbd).
This fixes rdar://problem/20609975
llvm-svn: 253060
|
| |
|
|
|
|
|
|
| |
While functions types are complete, they cannot be constructed.
This fixes PR25513.
llvm-svn: 253013
|
| |
|
|
|
|
|
|
|
| |
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
llvm-svn: 253010
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
llvm-svn: 252986
|
| |
|
|
| |
llvm-svn: 252971
|
| |
|
|
|
|
| |
due to ambiguity.
llvm-svn: 252967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
llvm-svn: 252960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):
* When performing name lookup for an elaborated-type-specifier, a tag
declaration hides a typedef declaration that names the same type.
* When performing any other kind of lookup, a typedef declaration hides
a tag declaration that names the same type.
In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).
llvm-svn: 252959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might define different internal linkage symbols with the same
name, and this isn't a problem unless two such symbols are simultaneously
visible.
The case where two modules define equivalent internal linkage symbols is
handled by r252063: if lookup finds multiple sufficiently-similar entities from
different modules, we just pick one of them as an extension (but we keep them
separate).
llvm-svn: 252957
|