summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] ConditionBRVisitor: Unknown condition evaluation supportCsaba Dabis2019-03-162-4/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: If the constraint information is not changed between two program states the analyzer has not learnt new information and made no report. But it is possible to happen because we have no information at all. The new approach evaluates the condition to determine if that is the case and let the user know we just `Assuming...` some value. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: llvm-commits, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gsd, gerazo Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D57410 llvm-svn: 356323
* Revert "[analyzer] ConditionBRVisitor: Unknown condition evaluation support"Csaba Dabis2019-03-162-10/+4
| | | | | | This reverts commit 0fe67a61cd4aec13c7969a179517f1cc06ab05cd. llvm-svn: 356320
* [analyzer] ConditionBRVisitor: Unknown condition evaluation supportCsaba Dabis2019-03-162-4/+10
| | | | | | | | | | | | | | | | Summary: If the constraint information is not changed between two program states the analyzer has not learnt new information and made no report. But it is possible to happen because we have no information at all. The new approach evaluates the condition to determine if that is the case and let the user know we just 'Assuming...' some value. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gsd, gerazo Tags: #clang Differential Revision: https://reviews.llvm.org/D57410 llvm-svn: 356319
* [analyzer] RetainCount: A function isn't a CFRetain if it takes no arguments.Artem Dergachev2019-03-151-0/+12
| | | | | | | | | | | | | Don't crash when a function has a name that starts with "CF" and ends with "Retain" but takes 0 arguments. In particular, don't try to treat it as if it returns its first argument. These problems are inevitable because the checker is naming-convention-based, but at least we shouldn't crash. Differential Revision: https://reviews.llvm.org/D59123 llvm-svn: 356223
* [analyzer] Support C++17 aggregates with bases without constructors.Artem Dergachev2019-03-151-4/+63
| | | | | | | | | | | | RegionStore now knows how to bind a nonloc::CompoundVal that represents the value of an aggregate initializer when it has its initial segment of sub-values correspond to base classes. Additionally, fixes the crash from pr40022. Differential Revision: https://reviews.llvm.org/D59054 llvm-svn: 356222
* [analyzer] Fix an assertation failure for invalid sourcelocation, add a new ↵Kristof Umann2019-03-142-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | debug checker For a rather short code snippet, if debug.ReportStmts (added in this patch) was enabled, a bug reporter visitor crashed: struct h { operator int(); }; int k() { return h(); } Ultimately, this originated from PathDiagnosticLocation::createMemberLoc, as it didn't handle the case where it's MemberExpr typed parameter returned and invalid SourceLocation for MemberExpr::getMemberLoc. The solution was to find any related valid SourceLocaion, and Stmt::getBeginLoc happens to be just that. Differential Revision: https://reviews.llvm.org/D58777 llvm-svn: 356161
* [analyzer] Fix function macro crashKristof Umann2019-03-142-0/+496
| | | | | | | | Re-commit D57893. Differential Revision: https://reviews.llvm.org/D57893 llvm-svn: 356142
* [Analyzer] Clean up test/Analysis/ptr-sort.cppMandeep Singh Grang2019-03-131-4/+5
| | | | llvm-svn: 356088
* [Analyzer] Skip symbolic regions based on conjured symbols in comparison of ↵Adam Balogh2019-03-131-0/+14
| | | | | | | | | | | | | | | | the containers of iterators Checking whether two regions are the same is a partially decidable problem: either we know for sure that they are the same or we cannot decide. A typical case for this are the symbolic regions based on conjured symbols. Two different conjured symbols are either the same or they are different. Since we cannot decide this and want to reduce false positives as much as possible we exclude these regions whenever checking whether two containers are the same at iterator mismatch check. Differential Revision: https://reviews.llvm.org/D53754 llvm-svn: 356049
* Revert "[analyzer] Fix function macro crash"Kristof Umann2019-03-122-496/+0
| | | | | | | | | Buildbot breaks when LLVm is compiled with memory sanitizer. WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xa3d16d8 in getMacroNameAndPrintExpansion(blahblah) lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:903:11 llvm-svn: 355911
* [analyzer] Fix function macro crashKristof Umann2019-03-122-0/+496
| | | | | | | | | | | | | | | | | | | When there is a functor-like macro which is passed as parameter to another "function" macro then its parameters are not listed at the place of expansion: #define foo(x) int bar() { return x; } #define hello(fvar) fvar(0) hello(foo) int main() { 1 / bar(); } Expansion of hello(foo) asserted Clang, because it expected an l_paren token in the 3rd line after "foo", since it is a function-like token. Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D57893 llvm-svn: 355903
* [Analyzer] Checker for non-determinism caused by sorting of pointer-like ↵Mandeep Singh Grang2019-03-082-0/+58
| | | | | | | | | | | | | | | | | | | | elements Summary: Added a new category of checkers for non-determinism. Added a checker for non-determinism caused due to sorting containers with pointer-like elements. Reviewers: NoQ, george.karpenkov, whisperity, Szelethus Reviewed By: NoQ, Szelethus Subscribers: Charusso, baloghadamsoftware, jdoerfert, donat.nagy, dkrupp, martong, dblaikie, MTC, Szelethus, mgorny, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50488 llvm-svn: 355720
* [analyzer] Fix infinite recursion in printing macrosKristof Umann2019-03-082-0/+145
| | | | | | | | | | | | | | | | | | | | In the commited testfile, macro expansion (the one implemented for the plist output) runs into an infinite recursion. The issue originates from the algorithm being faulty, as in #define value REC_MACRO_FUNC(value) the "value" is being (or at least attempted) expanded from the same macro. The solved this issue by gathering already visited macros in a set, which does resolve the crash, but will result in an incorrect macro expansion, that would preferably be fixed down the line. Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D57891 llvm-svn: 355705
* [analyzer] Emit an error rather than assert on invalid checker option inputKristof Umann2019-03-086-4/+44
| | | | | | | | | | | Asserting on invalid input isn't very nice, hence the patch to emit an error instead. This is the first of many patches to overhaul the way we handle checker options. Differential Revision: https://reviews.llvm.org/D57850 llvm-svn: 355704
* [analyzer] Handle comparison between non-default AS symbol and constantDavid Stenberg2019-03-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When comparing a symbolic region and a constant, the constant would be widened or truncated to the width of a void pointer, meaning that the constant could be incorrectly truncated when handling symbols for non-default address spaces. In the attached test case this resulted in a false positive since the constant was truncated to zero. To fix this, widen/truncate the constant to the width of the symbol expression's type. This commit does not consider non-symbolic regions as I'm not sure how to generalize getting the type there. This fixes PR40814. Reviewers: NoQ, zaks.anna, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, jdoerfert, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58665 llvm-svn: 355592
* [analyzer] Fix taint propagation in GenericTaintCheckerKristof Umann2019-03-051-0/+7
| | | | | | | | | | | The gets function has no SrcArgs. Because the default value for isTainted was false, it didn't mark its DstArgs as tainted. Patch by Gábor Borsik! Differential Revision: https://reviews.llvm.org/D58828 llvm-svn: 355396
* [analyzer] MIGChecker: Enable by default as `osx.MIG'.Artem Dergachev2019-02-221-1/+1
| | | | | | | | | | With r354643, the checker is feature-rich and polished enough. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58397 llvm-svn: 354644
* [analyzer] MIGChecker: Add support for more APIs.Artem Dergachev2019-02-221-0/+84
| | | | | | | | | | | | | | | Add more "consuming" functions. For now only vm_deallocate() was supported. Add a non-zero value that isn't an error; this value is -305 ("MIG_NO_REPLY") and it's fine to deallocate data when you are returning this error. Make sure that the mig_server_routine annotation is inherited. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58397 llvm-svn: 354643
* [analyzer] MIGChecker: Fix an FN when the object is released in a destructor.Artem Dergachev2019-02-221-0/+25
| | | | | | | | | | | | | | | | | When a MIG server routine argument is released in an automatic destructor, the Static Analyzer thinks that this happens after the return statement, and so the violation of the MIG convention doesn't happen. Of course, it doesn't quite work that way, so this is a false negative. Add a hack that makes the checker double-check at the end of function that no argument was released when the routine fails with an error. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58392 llvm-svn: 354642
* [analyzer] MIGChecker: Improve intermediate diagnostic notes.Artem Dergachev2019-02-221-5/+21
| | | | | | | | | | | | | | | | | | Add a BugReporterVisitor for highlighting the events of deallocating a parameter. All such events are relevant to the emitted report (as long as the report is indeed emitted), so all of them will get highlighted. Add a trackExpressionValue visitor for highlighting where does the error return code come from. Do not add a trackExpressionValue visitor for highlighting how the deallocated argument(s) was(were) copied around. This still remains to be implemented. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D58368 llvm-svn: 354641
* [analyzer] MIGChecker: Take advantage of the mig_server_routine annotation.Artem Dergachev2019-02-221-1/+49
| | | | | | | | | | | | | | | | r354530 has added a new function/block/message attribute "mig_server_routine" that attracts compiler's attention to functions that need to follow the MIG server routine convention with respect to deallocating out-of-line data that was passed to them as an argument. Teach the checker to identify MIG routines by looking at this attribute, rather than by making heuristic-based guesses. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/58366 llvm-svn: 354638
* [analyzer] MIGChecker: A checker for Mach Interface Generator conventions.Artem Dergachev2019-02-211-0/+36
| | | | | | | | | | | | | | | | | This checker detects use-after-free bugs in (various forks of) the Mach kernel that are caused by errors in MIG server routines - functions called remotely by MIG clients. The MIG convention forces the server to only deallocate objects it receives from the client when the routine is executed successfully. Otherwise, if the server routine exits with an error, the client assumes that it needs to deallocate the out-of-line data it passed to the server manually. This means that deallocating such data within the MIG routine and then returning a non-zero error code is always a dangerous use-after-free bug. rdar://problem/35380337 Differential Revision: https://reviews.llvm.org/D57558 llvm-svn: 354635
* [analyzer] Make valist.Uninitialized depend on ValistBaseKristof Umann2019-02-171-2/+12
| | | | | | | Accidentally left this dependency out, resulting in an assert failure if only valist.Uninitialized is enabled from the valist package. llvm-svn: 354235
* [Analyzer] Fix for test file of bug 40625Adam Balogh2019-02-151-4/+1
| | | | | | Test fixed and changed to true positive, FIXME about false positive removed. llvm-svn: 354127
* [Builtins] Treat `bcmp` as a builtin.Clement Courbet2019-02-142-3/+2
| | | | | | | | | | | | | | | | | Summary: This makes it consistent with `memcmp` and `__builtin_bcmp`. Also see the discussion in https://reviews.llvm.org/D56593. Reviewers: jyknight Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58120 llvm-svn: 354023
* [Analyzer] Crash fix for FindLastStoreBRVisitorAdam Balogh2019-02-132-4/+20
| | | | | | | | | | | | | | | | | | | | | | | FindLastStoreBRVisitor tries to find the first node in the exploded graph where the current value was assigned to a region. This node is called the "store site". It is identified by a pair of Pred and Succ nodes where Succ already has the binding for the value while Pred does not have it. However the visitor mistakenly identifies a node pair as the store site where the value is a `LazyCompoundVal` and `Pred` does not have a store yet but `Succ` has it. In this case the `LazyCompoundVal` is different in the `Pred` node because it also contains the store which is different in the two nodes. This error may lead to crashes (a declaration is cast to a parameter declaration without check) or misleading bug path notes. In this patch we fix this problem by checking for unequal `LazyCompoundVals`: if their region is equal, and their store is the same as the store of their nodes we consider them as equal when looking for the "store site". This is an approximation because we do not check for differences of the subvalues (structure members or array elements) in the stores. Differential Revision: https://reviews.llvm.org/D58067 llvm-svn: 353943
* [Sema] Mark GNU compound literal array init as an rvalue.Eli Friedman2019-02-111-2/+1
| | | | | | | | | | | | | | | | | | | | | | Basically the same issue as string init, except it didn't really have any visible consequences before I removed the implicit lvalue-to-rvalue conversion from CodeGen. While I'm here, a couple minor drive-by cleanups: IgnoreParens never returns a ConstantExpr, and there was a potential crash with string init involving a ChooseExpr. The analyzer test change maybe indicates we could simplify the analyzer code a little with this fix? Apparently a hack was added to support lvalues in initializers in r315750, but I'm not really familiar with the relevant code. Fixes regression reported in the kernel build at https://bugs.llvm.org/show_bug.cgi?id=40430#c6 . Differential Revision: https://reviews.llvm.org/D58069 llvm-svn: 353762
* [analyzer] New checker for detecting usages of unsafe I/O functionsKristof Umann2019-02-111-0/+82
| | | | | | | | | | | | | | | | There are certain unsafe or deprecated (since C11) buffer handling functions which should be avoided in safety critical code. They could cause buffer overflows. A new checker, 'security.insecureAPI.DeprecatedOrUnsafeBufferHandling' warns for every occurrence of such functions (unsafe or deprecated printf, scanf family, and other buffer handling functions, which now have a secure variant). Patch by Dániel Kolozsvári! Differential Revision: https://reviews.llvm.org/D35068 llvm-svn: 353698
* Fix test to pass on LLP64 targetsReid Kleckner2019-02-101-2/+2
| | | | llvm-svn: 353654
* [analyzer] CStringSyntaxChecks: Fix an off-by-one error in the strlcat() check.Artem Dergachev2019-02-081-0/+2
| | | | | | | | | | | | oth strlcat and strlcpy cut off their safe bound for the argument value at sizeof(destination). There's no need to subtract 1 in only one of these cases. Differential Revision: https://reviews.llvm.org/D57981 rdar://problem/47873212 llvm-svn: 353583
* [analyzer] Opt-in C Style Cast Checker for OSObject pointersGeorge Karpenkov2019-02-081-0/+39
| | | | | | Differential Revision: https://reviews.llvm.org/D57261 llvm-svn: 353566
* [analyzer] Canonicalize declarations within variable regions.Artem Dergachev2019-02-071-0/+15
| | | | | | | | | | | | | | | Memory region that correspond to a variable is identified by the variable's declaration and, in case of local variables, the stack frame it belongs to. The declaration needs to be canonical, otherwise we'd have two different memory regions that correspond to the same variable. Fix such bug for global variables with forward declarations and assert that no other problems of this kind happen. Differential Revision: https://reviews.llvm.org/D57619 llvm-svn: 353353
* Revert "[analyzer] Remove the "postponed" hack, deal with derived symbols..."Artem Dergachev2019-02-062-0/+43
| | | | | | | | | | | | | | This reverts commit r341722. The "postponed" mechanism turns out to be necessary in order to handle situations when a symbolic region is only kept alive by implicit bindings in the Store. Otherwise the region is never scanned by the Store's worklist and the binding gets dropped despite being live, as demonstrated by the newly added tests. Differential Revision: https://reviews.llvm.org/D57554 llvm-svn: 353350
* [analyzer] [RetainCountChecker] Bugfix: in non-OSObject-mode, do not track ↵George Karpenkov2019-02-051-1/+19
| | | | | | | | CXX method calls Differential Revision: https://reviews.llvm.org/D57782 llvm-svn: 353227
* [analyzer][UninitializedObjectChecker] New flag to ignore guarded ↵Kristof Umann2019-02-021-0/+440
| | | | | | | | | | | | | | | | | | | uninitialized fields This patch is an implementation of the ideas discussed on the mailing list[1]. The idea is to somewhat heuristically guess whether the field that was confirmed to be uninitialized is actually guarded with ifs, asserts, switch/cases and so on. Since this is a syntactic check, it is very much prone to drastically reduce the amount of reports the checker emits. The reports however that do not get filtered out though have greater likelihood of them manifesting into actual runtime errors. [1] http://lists.llvm.org/pipermail/cfe-dev/2018-September/059255.html Differential Revision: https://reviews.llvm.org/D51866 llvm-svn: 352959
* [analyzer] Hotfix for RetainCountChecker: assert was too strong.George Karpenkov2019-02-011-0/+15
| | | | | | Bridged casts can happen to non-CF objects as well. llvm-svn: 352938
* [analyzer] [RetainCountChecker] Fix object type for CF/Obj-C bridged castsGeorge Karpenkov2019-02-011-1/+14
| | | | | | | | | | | | 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. rdar://47709885 Differential Revision: https://reviews.llvm.org/D57557 llvm-svn: 352824
* [analyzer] Make NullReturnedFromNonnullChecker depend on NullabilityBaseKristof Umann2019-01-301-0/+3
| | | | | | Accidentally left this dependency out after D54438. llvm-svn: 352693
* [analyzer] [RetainCountChecker] Bugfix for tracking top-level parameters of ↵George Karpenkov2019-01-303-4306/+4323
| | | | | | | | Objective-C methods Differential Revision: https://reviews.llvm.org/D57433 llvm-svn: 352588
* [analyzer] [RetainCountChecker] Track input parameters to the top-level functionGeorge Karpenkov2019-01-294-6455/+6490
| | | | | | | | | | Track them for ISL/OS objects by default, and for NS/CF under a flag. rdar://47536377 Differential Revision: https://reviews.llvm.org/D57356 llvm-svn: 352534
* [analyzer] [RetainCountChecker] Support 'taggedRetain' and 'taggedRelease'George Karpenkov2019-01-293-6/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D57211 llvm-svn: 352530
* [analyzer] Toning down invalidation a bitGabor Horvath2019-01-295-7/+10
| | | | | | | | | When a function takes the address of a field the analyzer will no longer assume that the function will change other fields of the enclosing structs. Differential Revision: https://reviews.llvm.org/D57230 llvm-svn: 352473
* [ASTImporter] Fix handling of overriden methods during ASTImportShafik Yaghmour2019-01-282-14/+19
| | | | | | | | | 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. Differential Revision: https://reviews.llvm.org/D56936 llvm-svn: 352436
* [analyzer] Add CheckerManager::getChecker, make sure that a registry ↵Kristof Umann2019-01-264-5/+20
| | | | | | | | | | | | | 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. Differential Revision: https://reviews.llvm.org/D55429 llvm-svn: 352292
* [analyzer] Reimplement dependencies between checkersKristof Umann2019-01-2614-536/+568
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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! Differential Revision: https://reviews.llvm.org/D54438 llvm-svn: 352287
* [analyzer] Split unix.API up to UnixAPIMisuseChecker and ↵Kristof Umann2019-01-261-18/+18
| | | | | | | | | | | | | | | | UnixAPIPortabilityChecker The actual implementation of unix.API features a dual-checker: two checkers in one, even though they don't even interact at all. Split them up, as this is a problem for establishing dependencies. I added no new code at all, just merely moved it around. Since the plist files change (and that's a benefit!) this patch isn't NFC. Differential Revision: https://reviews.llvm.org/D55425 llvm-svn: 352278
* [analyzer] Insert notes in RetainCountChecker where our dynamic cast ↵George Karpenkov2019-01-221-1/+2
| | | | | | | | | | modeling assumes 'null' output rdar://47397214 Differential Revision: https://reviews.llvm.org/D56952 llvm-svn: 351865
* [analyzer] Model another special-case kind of cast for OSObject ↵George Karpenkov2019-01-222-0/+5
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D56951 llvm-svn: 351864
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-201-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* Emit !callback metadata and introduce the callback attributeJohannes Doerfert2019-01-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | With commit r351627, LLVM gained the ability to apply (existing) IPO optimizations on indirections through callbacks, or transitive calls. The general idea is that we use an abstraction to hide the middle man and represent the callback call in the context of the initial caller. It is described in more detail in the commit message of the LLVM patch r351627, the llvm::AbstractCallSite class description, and the language reference section on callback-metadata. This commit enables clang to emit !callback metadata that is understood by LLVM. It does so in three different cases: 1) For known broker functions declarations that are directly generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel. 2) For known broker functions that are identified by their name and source location through the builtin detection, e.g., pthread_create from the POSIX thread API. 3) For user annotated functions that carry the "callback(callee, ...)" attribute. The attribute has to include the name, or index, of the callback callee and how the passed arguments can be identified (as many as the callback callee has). See the callback attribute documentation for detailed information. Differential Revision: https://reviews.llvm.org/D55483 llvm-svn: 351629
OpenPOWER on IntegriCloud