Yevgeny Rouban [Fri, 1 Feb 2019 10:44:43 +0000 (10:44 +0000)]
Provide reason messages for unviable inlining
InlineCost's isInlineViable() is changed to return InlineResult
instead of bool. This provides messages for failure reasons and
allows to get more specific messages for cases where callsites
are not viable for inlining.
Serge Guelton [Fri, 1 Feb 2019 06:11:44 +0000 (06:11 +0000)]
Fix isInSystemMacro to handle pasted macros
Token pasted by the preprocessor (through ##) have a Spelling pointing to scratch buffer.
As a result they are not recognized at system macro, even though the pasting happened in
a system macro. Fix that by looking into the parent macro if the original lookup finds a
scratch buffer.
Brian Gesiak [Fri, 1 Feb 2019 03:30:29 +0000 (03:30 +0000)]
[SemaCXX] Param diagnostic matches overload logic
Summary:
Given the following test program:
```
class C {
public:
int A(int a, int& b);
};
int C::A(const int a, int b) {
return a * b;
}
```
Clang would produce an error message that correctly diagnosed the
redeclaration of `C::A` to not match the original declaration (the
parameters to the two declarations do not match -- the original takes an
`int &` as its 2nd parameter, but the redeclaration takes an `int`). However,
it also produced a note diagnostic that inaccurately pointed to the
first parameter, claiming that `const int` in the redeclaration did not
match the unqualified `int` in the original. The diagnostic is
misleading because it has nothing to do with why the program does not
compile.
The logic for checking for a function overload, in
`Sema::FunctionParamTypesAreEqual`, discards cv-qualifiers before
checking whether the types are equal. Do the same when producing the
overload diagnostic.
Julian Lettner [Fri, 1 Feb 2019 02:51:00 +0000 (02:51 +0000)]
[Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls
Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every unreachable instruction. However, the
optimizer will remove code after calls to functions marked with
noreturn. To avoid this UBSan removes noreturn from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
_asan_handle_no_return before noreturn functions. This is important for
functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* longjmp (longjmp itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the noreturn attributes are missing and ASan cannot
unpoison the stack, so it has false positives when stack unwinding is
used.
Changes:
Clang-CodeGen now directly insert calls to `__asan_handle_no_return`
when a call to a noreturn function is encountered and both
UBsan-unreachable and ASan are enabled. This allows UBSan to continue
removing the noreturn attribute from functions without any changes to
the ASan pass.
James Y Knight [Fri, 1 Feb 2019 02:28:03 +0000 (02:28 +0000)]
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
[analyzer] [RetainCountChecker] Fix object type for CF/Obj-C bridged casts
Having an incorrect type for a cast causes the checker to incorrectly
dismiss the operation under ARC, leading to a false positive
use-after-release on the test.
Akira Hatanaka [Fri, 1 Feb 2019 00:12:06 +0000 (00:12 +0000)]
Revert "[Sema] Make canPassInRegisters return true if the CXXRecordDecl passed"
This reverts commit r350920 as it is not clear whether we should force a
class to be returned in registers when copy and move constructors are
both deleted.
For more background, see the following discussion:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190128/259907.html
[sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions that feed into the backedge branch. Instrumenting these CMP instructions is almost always useless (and harmful) for fuzzing
Nico Weber [Thu, 31 Jan 2019 22:15:32 +0000 (22:15 +0000)]
Make clang/test/Index/pch-from-libclang.c pass in more places
- fixes the test on macOS with LLVM_ENABLE_PIC=OFF
- together with D57343, gets the test to pass on Windows
- makes it run everywhere (it seems to just pass on Linux)
The main change is to pull out the resource directory computation into a
function shared by all 3 places that do it. In CIndexer.cpp, this now works no
matter if libclang is in lib/ or bin/ or statically linked to a binary in bin/.
Artem Belevich [Thu, 31 Jan 2019 21:34:03 +0000 (21:34 +0000)]
[CUDA] add support for the new kernel launch API in CUDA-9.2+.
Instead of calling CUDA runtime to arrange function arguments,
the new API constructs arguments in a local array and the kernels
are launched with __cudaLaunchKernel().
The old API has been deprecated and is expected to go away
in the next CUDA release.
Artem Belevich [Thu, 31 Jan 2019 21:32:24 +0000 (21:32 +0000)]
[CUDA] Propagate detected version of CUDA to cc1
..and use it to control that parts of CUDA compilation
that depend on the specific version of CUDA SDK.
This patch has a placeholder for a 'new launch API' support
which is in a separate patch. The list will be further
extended in the upcoming patch to support CUDA-10.1.
James Y Knight [Thu, 31 Jan 2019 20:35:56 +0000 (20:35 +0000)]
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Ilya Biryukov [Thu, 31 Jan 2019 20:20:32 +0000 (20:20 +0000)]
[CodeComplete] Propagate preferred types through parser in more cases
Preferred types are used by code completion for ranking. This commit
considerably increases the number of points in code where those types
are propagated.
In order to avoid complicating signatures of Parser's methods, a
preferred type is kept as a member variable in the parser and updated
during parsing.
Rafael Auler [Thu, 31 Jan 2019 09:38:31 +0000 (09:38 +0000)]
Support attribute used in member funcs of class templates
Summary:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.
Petr Hosek [Thu, 31 Jan 2019 06:21:01 +0000 (06:21 +0000)]
[CMake] Unify scripts for generating VCS headers
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.
Julian Lettner [Wed, 30 Jan 2019 23:42:13 +0000 (23:42 +0000)]
[Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls
Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every unreachable instruction. However, the
optimizer will remove code after calls to functions marked with
noreturn. To avoid this UBSan removes noreturn from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
_asan_handle_no_return before noreturn functions. This is important for
functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* longjmp (longjmp itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the noreturn attributes are missing and ASan cannot
unpoison the stack, so it has false positives when stack unwinding is
used.
Changes:
Clang-CodeGen now directly insert calls to `__asan_handle_no_return`
when a call to a noreturn function is encountered and both
UBsan-unreachable and ASan are enabled. This allows UBSan to continue
removing the noreturn attribute from functions without any changes to
the ASan pass.
Erik Pilkington [Wed, 30 Jan 2019 23:17:38 +0000 (23:17 +0000)]
[CodeGenObjC] Handle exceptions when calling objc_alloc or objc_allocWithZone
objc_alloc and objc_allocWithZone may throw exceptions if the
underlying method does. If we're in a @try block, then make sure we
emit an invoke instead of a call.
Alexey Bataev [Wed, 30 Jan 2019 20:49:52 +0000 (20:49 +0000)]
[OPENMP]Fix PR40536: Do not emit __kmpc_push_target_tripcount if not
required.
Function __kmpc_push_target_tripcount should be emitted only if the
offloading entry is going to be emitted (for use in tgt_target...
functions). Otherwise, it should not be emitted.
Erik Pilkington [Wed, 30 Jan 2019 20:34:53 +0000 (20:34 +0000)]
Add a new builtin: __builtin_dynamic_object_size
This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:
void f(size_t alloc) {
char* p = malloc(alloc);
strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
}
This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.
Erik Pilkington [Wed, 30 Jan 2019 20:34:35 +0000 (20:34 +0000)]
Add a 'dynamic' parameter to the objectsize intrinsic
This is meant to be used with clang's __builtin_dynamic_object_size.
When 'true' is passed to this parameter, the intrinsic has the
potential to be folded into instructions that will be evaluated
at run time. When 'false', the objectsize intrinsic behaviour is
unchanged.
Yaxun Liu [Wed, 30 Jan 2019 12:26:54 +0000 (12:26 +0000)]
[HIP] Fix size_t for MSVC environment
In 64 bit MSVC environment size_t is defined as unsigned long long.
In single source language like HIP, data layout should be consistent
in device and host compilation, therefore copy data layout controlling
fields from Aux target for AMDGPU target.
[OpenCL] Add generic addr space to the return of implicit assignment.
When creating the prototype of implicit assignment operators the
returned reference to the class should be qualified with the same
addr space as 'this' (i.e. __generic in OpenCL).
Michal Gorny [Wed, 30 Jan 2019 08:20:24 +0000 (08:20 +0000)]
[clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimes
Append appropriate -rpath when using shared compiler-rt runtimes,
e.g. '-fsanitize=address -shared-libasan'. There's already a similar
logic in CommonArgs.cpp but it uses non-standard arch-suffixed
installation directory while we want our driver to work with standard
installation paths.
We don't need to use the predetermined data-sharing attributes for the
loop counters if the user explicitly specified correct data-sharing
attributes for such variables.
Matt Arsenault [Tue, 29 Jan 2019 20:49:54 +0000 (20:49 +0000)]
OpenCL: Use length modifier for warning on vector printf arguments
Re-enable format string warnings on printf.
The warnings are still incomplete. Apparently it is undefined to use a
vector specifier without a length modifier, which is not currently
warned on. Additionally, type warnings appear to not be working with
the hh modifier, and aren't warning on all of the special restrictions
from c99 printf.
George Karpenkov [Tue, 29 Jan 2019 19:29:19 +0000 (19:29 +0000)]
Extend AnyCall to handle callable declarations without the call expressions
That weakens inner invariants, but allows the class to be more generic,
allowing usage in situations where the call expression is not known (or
should not matter).
Alexey Bataev [Tue, 29 Jan 2019 18:51:58 +0000 (18:51 +0000)]
[OPENMP]Make the loop with unsigned counter countable.
According to the report, better to keep the original strict compare
operation as the loop condition with unsigned loop counters to make the
loop countable. This allows further loop transformations.
James Y Knight [Tue, 29 Jan 2019 16:37:27 +0000 (16:37 +0000)]
Adjust documentation for git migration.
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Yaxun Liu [Tue, 29 Jan 2019 13:20:23 +0000 (13:20 +0000)]
[CUDA][HIP] Do not diagnose use of _Float16
r352221 caused regressions in CUDA/HIP since device function may use _Float16 whereas host does not support it.
In this case host compilation should not diagnose usage of _Float16 in device functions or variables.
For now just do not diagnose _Float16 for CUDA/HIP. In the future we should have more precise check.
Shafik Yaghmour [Mon, 28 Jan 2019 21:55:33 +0000 (21:55 +0000)]
[ASTImporter] Fix handling of overriden methods during ASTImport
Summary:
When importing classes we may add a CXXMethodDecl more than once to a CXXRecordDecl when handling overrides. This patch will fix the cases we currently know about and handle the case where we are only dealing with declarations.
Scott Linder [Mon, 28 Jan 2019 17:12:19 +0000 (17:12 +0000)]
Add -fapply-global-visibility-to-externs for -cc1
Introduce an option to request global visibility settings be applied to
declarations without a definition or an explicit visibility, rather than
the existing behavior of giving these default visibility. When the
visibility of all or most extern definitions are known this allows for
the same optimisations -fvisibility permits without updating source code
to annotate all declarations.
Roman Lebedev [Mon, 28 Jan 2019 17:04:11 +0000 (17:04 +0000)]
[clang][OpenMP] OMPFlushClause is synthetic, no such clause exists
Summary:
As discussed in https://reviews.llvm.org/D57112#inline-506781,
'flush' clause does not exist in the OpenMP spec, it can not be
specified, and `OMPFlushClause` class is just a helper class.
Therefore `OPENMP_CLAUSE()` in `clang/Basic/OpenMPKinds.def`
should not contain 'flush' "clause".
I have simply removed the `OPENMP_CLAUSE(flush, OMPFlushClause)`
from `clang/Basic/OpenMPKinds.def`, grepped for `OPENMP_CLAUSE`
and added `OPENMP_CLAUSE(flush, OMPFlushClause)` back to the **every**
place where `OPENMP_CLAUSE` is defined and `clang/Basic/OpenMPKinds.def`
is then included.
So as-is, this patch is a NFC. Possibly, some of these
`OPENMP_CLAUSE(flush, OMPFlushClause)` should be dropped,
i don't really know.
Bruno Ricci [Mon, 28 Jan 2019 14:18:11 +0000 (14:18 +0000)]
[AST] Introduce GenericSelectionExpr::Association
Introduce a new class GenericSelectionExpr::Association which bundle together
an association expression and its TypeSourceInfo.
An iterator GenericSelectionExpr::AssociationIterator is additionally added to
make it possible to iterate over ranges of Associations. This iterator is a
kind of proxy iterator which abstract over how exactly the expressions and the
TypeSourceInfos are stored.
Nicolas Lesser [Sun, 27 Jan 2019 19:19:59 +0000 (19:19 +0000)]
[SemaCXX] Fix ICE with structure bindings to members of template
Summary:
Trying to use structure binding with a structure that doesn't implement
std::tuple_size, should unpack the data members. When the struct is a
template though, clang might hit an assertion (if the type has not been
completed before), because CXXRecordDecl::DefinitionData is nullptr.
This commit fixes the problem by completing the type while trying to
decompose the structured binding.
The ICE happens in real world code, for example, when trying to iterate
a protobuf generated map with a range-based for loop and structure
bindings (because google::protobuf::MapPair is a template and doesn't
support std::tuple_size).
Reported-by: nicholas.sun@nlsun.com
Patch by Daniele Di Proietto
Kristof Umann [Sat, 26 Jan 2019 21:41:50 +0000 (21:41 +0000)]
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue.
The solution is to assert when CheckerManager::getChecker is called on an
unregistered checker, and assert when CheckerManager::registerChecker is called
on a checker that is already registered.
Kristof Umann [Sat, 26 Jan 2019 20:06:54 +0000 (20:06 +0000)]
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Kristof Umann [Sat, 26 Jan 2019 17:27:40 +0000 (17:27 +0000)]
[analyzer] Fix an bug where statically linked, but not registered checkers weren't recognized
My last patch, D56989, moved the validation of whether a checker exists into
its constructor, but we do support statically linked (and non-plugin) checkers
that were do not have an entry in Checkers.td. However, the handling of this
happens after the creation of the CheckerRegistry object.
This patch fixes this bug by moving even this functionality into
CheckerRegistry's constructor.
Kristof Umann [Sat, 26 Jan 2019 16:35:33 +0000 (16:35 +0000)]
[analyzer][NFC] Keep track of whether enabling a checker was explictly specified in command line arguments
I added a new enum to CheckerInfo, so we can easily track whether the check is
explicitly enabled, explicitly disabled, or isn't specified in this regard.
Checkers belonging in the latter category may be implicitly enabled through
dependencies in the followup patch. I also made sure that this is done within
CheckerRegisty's constructor, leading to very significant simplifications in
its query-like methods.