Summary:
Emitting deferred diagnostics during codegen was a hack. It did work,
but usability was poor, both for us as compiler devs and for users. We
don't codegen if there are any sema errors, so for users this meant that
they wouldn't see deferred errors if there were any non-deferred errors.
For devs, this meant that we had to carefully split up our tests so that
when we tested deferred errors, we didn't emit any non-deferred errors.
This change moves checking for deferred errors into Sema. See the big
comment in SemaCUDA.cpp for an overview of the idea.
This checking adds overhead to compilation, because we have to maintain
a partial call graph. As a result, this change makes deferred errors a
CUDA-only concept (whereas before they were a general concept). If
anyone else wants to use this framework for something other than CUDA,
we can generalize at that time.
This patch makes the minimal set of test changes -- after this lands,
I'll go back through and do a cleanup of the tests that we no longer
have to split up.
Reviewers: rnk
Subscribers: cfe-commits, rsmith, tra
Differential Revision: https://reviews.llvm.org/D25541
llvm-svn: 284158
Original message:
"[modules] PR28752: Do not instantiate variable declarations which are not visible.
https://reviews.llvm.org/D24508
Patch developed in collaboration with Richard Smith!"
llvm-svn: 284008
This affects functions with the C++11 [[ noreturn ]] and C11 _Noreturn
specifiers.
Patch by Victor Leschuk!
https://reviews.llvm.org/D23168
llvm-svn: 278942
Summary:
This patch lets you create diagnostics that are emitted if and only if a
particular FunctionDecl is codegen'ed.
This is necessary for CUDA, where some constructs -- e.g. calls from
host+device functions to host functions when compiling for device -- are
allowed to appear in semantically-correct programs, but only if they're
never codegen'ed.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D23241
llvm-svn: 278735
Reapply r277787. For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 278264
For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 277787
We continue accepting "macosx" but canonicalize it to "macos", When emitting
diagnostics, we use "macOS" instead of "OS X".
The PlatformName in TargetInfo is changed from "macosx" to "macos" so we can
directly compare the Platform in AvailabilityAttr with the PlatformName
in TargetInfo.
rdar://26795172
rdar://26800775
llvm-svn: 274064
declared before it is used. Because we don't use normal name lookup to find
these, the normal code to filter out non-visible names from name lookup results
does not apply.
llvm-svn: 268585
This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function alias with type @gnu_indirect_function. LLVM
patch http://reviews.llvm.org/D15525
Differential Revision: http://reviews.llvm.org/D15524
llvm-svn: 265917
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
This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.
llvm-svn: 262506
`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.
Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)
http://reviews.llvm.org/D17799
llvm-svn: 262493
The library functions defined in the C99 standard headers
are not available (OpenCL v1.2 s6.9.f).
This change stops treating OpenCL builtin functions as standard C lib
functions to eliminate warning messages about printf format string.
Patch by Liu Yaxun (Sam)!
Differential Revision: http://reviews.llvm.org/D16812
llvm-svn: 260671
__GetExceptionInfo triggered Sema::LazilyCreateBuiltin which tries to
create a non-templated function decl. This is unnecessary and
ill-advised, there is no need for us to create a declaration for such a
builtin.
This fixes PR26298.
llvm-svn: 258762
into IDNS_Tag in C++, because they conflict with redeclarations of tags. (This
doesn't affect elaborated-type-specifier lookup, which looks for IDNS_Type in
C++).
llvm-svn: 256985
keys, and PointerIntPairs where the pointee types are incomplete
out-of-line to where we have the complete type.
This is the standard pattern used throughout the AST library to address
the inherently mutually cross referenced nature of the AST.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256612
indicating the nature of the default argument in a ParmVarDecl.
Instead, this adds a proper enum stored exclusively in the ParmVarDecl
bits (which we have plenty of) for this. This even allows us to track
a previously unrepresented state in Clang when we parse a function
declaration with a default argument on a parameter but we cannot even
form an invalid expression node (for example, it is an invalid token).
Now, we can model this state in the AST at least, and potentially
improve recovery in this area in the future.
I've also cleaned up the functions managing both variable initializer
expressions and parameter default argument expresssions as much as
possible. I've left some comments about further improvements based on
a discussion with Richard Smith. Lots of credit to him for walking me
through exactly which of the *many* tradeoffs here he felt was the best
fit.
Should be NFC for now. I've tried my best to preserve existing behavior.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256609
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
llvm-svn: 256601
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
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
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
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
Summary: Use "auto" when the type name is redundant
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14501
llvm-svn: 252494
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
No ABI for C++ currently makes it possible to implement the standard
100% perfectly. We wrongly hid some of our compatible behavior behind
-fms-compatibility instead of tying it to the compiler ABI.
llvm-svn: 249656
- Remove virtual SC_OpenCLWorkGroupLocal storage type specifier
as it conflicts with static local variables now and prevents
diagnosing static local address space variables correctly.
- Allow static local and global variables (OpenCL2.0 s6.8 and s6.5.1).
- Improve diagnostics of allowed ASes for variables in different scopes:
(i) Global or static local variables have to be in global
or constant ASes (OpenCL1.2 s6.5, OpenCL2.0 s6.5.1);
(ii) Non-kernel function variables can't be declared in local
or constant ASes (OpenCL1.1 s6.5.2 and s6.5.3).
http://reviews.llvm.org/D13105
llvm-svn: 248906
A class without a name for linkage purposes gets a name along the lines
of <unnamed-type-foo> where foo is either the name of a declarator which
defined it (like a variable or field) or a
typedef-name (like a typedef or alias-declaration).
We handled the declarator case correctly but it would fall down during
template instantiation if the declarator didn't share the tag's type.
We failed to handle the typedef-name case at all.
Instead, keep track of the association between the two and keep it up to
date in the face of template instantiation.
llvm-svn: 246469
This initial commit serves as an example -- the remainder of the
classes using pointer arithmetic for trailing objects will be
converted in subsequent changes.
Differential Revision: http://reviews.llvm.org/D11298
llvm-svn: 244262
useless return value. Switch to using it directly when completing the
redeclaration chain for an anonymous declaration, and reduce the set of
declarations that we load in the process to just those of the right kind.
llvm-svn: 244161
Justin Lebar