| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
|
|
|
|
|
|
|
| |
rare issues with nondeterministic diagnostic order, and some very common issues
with nondeterministic module builds.
llvm-svn: 264323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as
#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182
llvm-svn: 262582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we import a module that has a complete array type and one that has an
incomplete array type, the declaration found by name lookup might be the one with
the incomplete type, possibly resulting in rejects-valid.
Now, the name lookup prefers decls with a complete array types. Also,
diagnose cases when the redecl chain has array bound, different from the merge
candidate.
Reviewed by Richard Smith.
llvm-svn: 262189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thousands of modules, each of which declares the same namespace, linearly
scanning the redecl chain looking for a visible declaration (once for each leaf
module, for each use) performs very poorly. Namespace visibility can only
decrease when we leave a module during a module build step, and we never care
*which* visible declaration of a namespace we find, so we can cache this very
effectively.
This results in a 35x speedup on one of our internal build steps (2m -> 3.5s),
but is hard to unit test because it requires a very large number of modules.
Ideas for a test appreciated! No functionality change intended other than the
speedup.
llvm-svn: 261161
|
|
|
|
| |
llvm-svn: 260124
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL builtin functions are usually declared in header files.
Currently clang emits warning for OpenCL builtin functions
which have the same name as standard C library functions.
This commit eliminates such warnings by not adding the C standard
includes following the restriction from OpenCL v1.2 s6.9.f.
Patch by Liu Yaxun (Sam)!
Review: http://reviews.llvm.org/D16692
llvm-svn: 259491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add "enum ObjCPropertyQueryKind" to a few APIs that used to only take the name
of the property: ObjCPropertyDecl::findPropertyDecl,
ObjCContainerDecl::FindPropertyDeclaration,
ObjCInterfaceDecl::FindPropertyVisibleInPrimaryClass,
ObjCImplDecl::FindPropertyImplDecl, and Sema::ActOnPropertyImplDecl.
ObjCPropertyQueryKind currently has 3 values:
OBJC_PR_query_unknown, OBJC_PR_query_instance, OBJC_PR_query_class
This extra parameter specifies that we are looking for an instance property with
the given name, or a class property with the given name, or any property with
the given name (if both exist, the instance property will be returned).
rdar://23891898
llvm-svn: 259070
|
|
|
|
|
|
|
|
| |
1) When dumping a declaration that declares a name for a type, also dump the named type.
2) Add a #pragma clang __debug dump X, that dumps the lookup results for X in
the current context.
llvm-svn: 257529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
|
|
|
|
|
|
|
|
|
|
| |
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
llvm-svn: 256575
|
|
|
|
|
|
|
| |
underlying declaration of a NamedDecl happens to always have the same name
and identifier namespace as the decl itself today).
llvm-svn: 256529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
llvm-svn: 256049
|
|
|
|
|
|
|
| |
RequireCompleteType(..., 0) says we're not permitted to do so. The definition
might not be visible, even though we know what it is.
llvm-svn: 256045
|
|
|
|
| |
llvm-svn: 254013
|
|
|
|
|
|
| |
Inspired by similar commits from Craig Topper.
llvm-svn: 253904
|
|
|
|
|
|
|
|
|
|
|
|
| |
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
llvm-svn: 253495
|
|
|
|
| |
llvm-svn: 253456
|
|
|
|
|
|
|
|
| |
unsafe, since many operations on the types can trigger lazy deserialization of
more types and invalidate the iterators. This fixes a crasher, but I've not
been able to reduce it to a reasonable testcase yet.
llvm-svn: 253420
|
|
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
internal linkage entities in different modules from r250884 to apply to all
names, not just function names.
This is really awkward: we don't want to merge internal-linkage symbols from
separate modules, because they might not actually be defining the same entity.
But we don't want to reject programs that use such an ambiguous symbol if those
internal-linkage symbols are in fact equivalent. For now, we're resolving the
ambiguity by picking one of the equivalent definitions as an extension.
llvm-svn: 252063
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
llvm-svn: 252036
|
|
|
|
|
|
|
|
|
| |
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not true when the same name is
declared multiple times as internal-linkage symbols within a module.
(getCanonicalDecl is cheap now, so we can just use it here.)
llvm-svn: 251898
|
|
|
|
|
|
|
|
|
|
| |
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replace empty bodies of default constructors and destructors with '= default'.
Reviewers: bkramer, klimek
Subscribers: klimek, alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D13890
llvm-svn: 250822
|
|
|
|
|
|
|
| |
emacs mode marker. (Changes left behind from another patch that ended up not
working out.)
llvm-svn: 250666
|
|
|
|
|
|
|
|
|
|
| |
minor cleanups
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13406
llvm-svn: 249484
|
|
|
|
|
|
|
|
| |
With -fms-extensions it is possible to have a non-class record that is a
template specialization cause an assertion failure via the call to
Type::getAsCXXRecordDecl. Fixes PR 24246.
llvm-svn: 249090
|
|
|
|
|
|
|
|
| |
it's not sufficient to prefer the declaration with more default arguments, or
the one that's visible; they might both be visible, but one of them might have
a visible default argument where the other has a hidden default argument.
llvm-svn: 247486
|
|
|
|
|
|
| |
rdar://22464808
llvm-svn: 247207
|
|
|
|
|
|
| |
whether the owning module of a hidden declaration is visible -- it can't be.
llvm-svn: 245822
|
|
|
|
|
|
|
| |
pick the most recent declaration, and we can often tell which declaration is
more recent without walking the redeclaration chain. Do so when possible.
llvm-svn: 245794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
|
|
|
|
|
|
|
|
|
|
| |
UsingShadowDecls over other declarations of the same entity in the lookup
results. This ensures that we build correct redeclaration chains for the
UsingShadowDecls (otherwise we could see assertions and other misbehavior in
modules builds, when merging combines multiple redeclaration chains for the
same entity from the same module into one chain).
llvm-svn: 243592
|
|
|
|
|
|
|
|
|
| |
This lets us pass functors (and lambdas) without void * tricks. On the
downside we can't pass CXXRecordDecl's Find* members (which are now type
safe) to lookupInBases directly, but a lambda trampoline is a small
price to pay. No functionality change intended.
llvm-svn: 243217
|
|
|
|
|
|
|
|
|
| |
the identifier table. This is redundant, since the TU-scope lookups are also
serialized as part of the TU DeclContext, and wasteful in a number of ways. We
still emit the decls for PCH / preamble builds, since for those we want
identical results, not merely semantically equivalent ones.
llvm-svn: 242855
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
| |
that we know when its default arguments should be visible.
llvm-svn: 239936
|
|
|
|
|
|
| |
argument is not visible.
llvm-svn: 239934
|
|
|
|
|
|
|
| |
Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.
llvm-svn: 239750
|
|
|
|
| |
llvm-svn: 239578
|
|
|
|
|
|
|
| |
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
llvm-svn: 239485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
llvm-svn: 239371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
|
|
|
|
|
|
| |
an imported but hidden one.
llvm-svn: 237814
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
|
|
|
|
|
|
| |
module rather than requiring them to work it out themselves.
llvm-svn: 237416
|
|
|
|
|
|
| |
imported but not visible definition.
llvm-svn: 236690
|