| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I intend to improve the analyzer's bug reports by tracking condition
expressions.
01 bool b = messyComputation();
02 int i = 0;
03 if (b) // control dependency of the bug site, let's explain why we assume val
04 // to be true
05 10 / i; // warn: division by zero
I'll detail this heuristic in the followup patch, strictly related to this one
however:
* Create the new ControlDependencyCalculator class that uses llvm::IDFCalculator
to (lazily) calculate control dependencies for Clang's CFG.
* A new debug checker debug.DumpControlDependencies is added for lit tests
* Add unittests
Differential Revision: https://reviews.llvm.org/D62619
llvm-svn: 365197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
like all other arg types do
This fixes an 8-year-old regression. r105763 made it so that aliases
always refer to the unaliased option – but it missed the "joined" branch
of JoinedOrSeparate flags. (r162231 then made the Args classes
non-virtual, and r169344 moved them from clang to llvm.)
Back then, there was no JoinedOrSeparate flag that was an alias, so it
wasn't observable. Now /U in CLCompatOptions is a JoinedOrSeparate alias
in clang, and warn_slash_u_filename incorrectly used the aliased arg id
(using the unaliased one isn't really a regression since that warning
checks if the undefined macro contains slash or backslash and only then
emits the warning – and no valid use will pass "-Ufoo/bar" or similar).
Also, lld has many JoinedOrSeparate aliases, and due to this bug it had
to explicitly call `getUnaliasedOption()` in a bunch of places, even
though that shouldn't be necessary by design. After this fix in Option,
these calls really don't have an effect any more, so remove them.
No intended behavior change.
(I accidentally fixed this bug while working on PR29106 but then
wondered why the warn_slash_u_filename broke. When I figured it out, I
thought it would make sense to land this in a separate commit.)
Differential Revision: https://reviews.llvm.org/D64156
llvm-svn: 365186
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getTerminatorCondition() returned a condition that may be outside of the
block, while the new function returns the proper one:
if (A && B && C) {}
Return C instead of A && B && C.
Differential Revision: https://reviews.llvm.org/D63538
llvm-svn: 365177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this fix gcc (7.4) complains with
/data/repo/master/clang/lib/CodeGen/CGObjCMac.cpp: In member function 'std::__cxx11::string {anonymous}::CGObjCCommonMac::GetSectionName(llvm::StringRef, llvm::StringRef)':
/data/repo/master/clang/lib/CodeGen/CGObjCMac.cpp:4944:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
All values in the ObjectFormatType enum are currently handled in the switch
but gcc complains anyway.
llvm-svn: 365174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch removes the `default` case from some switches on
`llvm::Triple::ObjectFormatType`, and cases for the missing enumerators
are then added.
For `UnknownObjectFormat`, the action (`llvm_unreachable`) for the
`default` case is kept.
For the other unhandled cases, `report_fatal_error` is used instead.
Reviewers: sfertile, jasonliu, daltenty
Reviewed By: sfertile
Subscribers: wuzish, aheejin, jsji, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D63767
llvm-svn: 365160
|
|
|
|
| |
llvm-svn: 365153
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: Szelethus, xazax.hun
Subscribers: rnkovacs, dkrupp, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63920
llvm-svn: 365133
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
"ww" and "ws" are both constraint codes for VSX vector registers that
hold scalar double data. "ww" is preferred for float while "ws" is
preferred for double.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D64119
llvm-svn: 365106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function calls
Summary: It models the known LLVM methods paired with their class.
Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus
Reviewed By: NoQ
Subscribers: dschuff, aheejin, mgorny, szepet, rnkovacs, a.sidorin,
mikhail.ramalho, donat.nagy, dkrupp, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63915
llvm-svn: 365103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.
Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru
Subscribers: arphaman, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63503
llvm-svn: 365092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.
This is needed to avoid a circular dependency when using the bitstream
code for parsing optimization remarks.
Since Bitcode uses Core for the IR part:
libLLVMRemarks -> Bitcode -> Core
and Core uses libLLVMRemarks to generate remarks (see
IR/RemarkStreamer.cpp):
Core -> libLLVMRemarks
we need to separate the Bitstream and Bitcode part.
For clang-doc, it seems that it doesn't need the whole bitcode layer, so
I updated the CMake to only use the bitstream part.
Differential Revision: https://reviews.llvm.org/D63899
llvm-svn: 365091
|
|
|
|
|
|
|
|
| |
This reverts commit 7a57118a6fcfa3770f984453543bbdfd0b233e84.
Causes a bunch of crashes, I need to time to evaluate this.
llvm-svn: 365037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the following terminator statement:
if (A && B && C && D)
The built CFG is the following:
[B5 (ENTRY)]
Succs (1): B4
[B1]
1: 10
2: j
3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
4: [B1.1] / [B1.3]
5: int x = 10 / j;
Preds (1): B2
Succs (1): B0
[B2]
1: C
2: [B2.1] (ImplicitCastExpr, LValueToRValue, _Bool)
T: if [B4.4] && [B3.2] && [B2.2]
Preds (1): B3
Succs (2): B1 B0
[B3]
1: B
2: [B3.1] (ImplicitCastExpr, LValueToRValue, _Bool)
T: [B4.4] && [B3.2] && ...
Preds (1): B4
Succs (2): B2 B0
[B4]
1: 0
2: int j = 0;
3: A
4: [B4.3] (ImplicitCastExpr, LValueToRValue, _Bool)
T: [B4.4] && ...
Preds (1): B5
Succs (2): B3 B0
[B0 (EXIT)]
Preds (4): B1 B2 B3 B4
However, even though the path of execution in B2 only depends on C's value,
CFGBlock::getCondition() would return the entire condition (A && B && C). For
B3, it would return A && B. I changed this the actual condition.
Differential Revision: https://reviews.llvm.org/D63538
llvm-svn: 365036
|
|
|
|
| |
llvm-svn: 365031
|
|
|
|
|
|
|
|
|
| |
When specializing a template in a namespace, it has to be in a namespace
block, else gcc will get confused. Hopefully this fixes the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480
llvm-svn: 365030
|
|
|
|
| |
llvm-svn: 365029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Transform clang::DominatorTree to be able to also calculate post dominators.
* Tidy up the documentation
* Make it clang::DominatorTree template class (similarly to how
llvm::DominatorTreeBase works), rename it to clang::CFGDominatorTreeImpl
* Clang's dominator tree is now called clang::CFGDomTree
* Clang's brand new post dominator tree is called clang::CFGPostDomTree
* Add a lot of asserts to the dump() function
* Create a new checker to test the functionality
Differential Revision: https://reviews.llvm.org/D62551
llvm-svn: 365028
|
|
|
|
|
|
| |
Fixes PR42426.
llvm-svn: 365019
|
|
|
|
| |
llvm-svn: 365012
|
|
|
|
|
|
| |
llvm::partition_point. NFC
llvm-svn: 365006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently HeaderSearch only looks at SearchDir's passed into it, but in
addition to those paths headers can be relative to including file's directory.
This patch makes sure that is taken into account.
Reviewers: gribozavr
Subscribers: jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63295
llvm-svn: 365005
|
|
|
|
|
|
|
|
|
|
|
| |
Add a label to nodes that have a bug report attached or on which
the analysis was generally interrupted.
Fix printing has_report and implement printing is_sink in the graph dumper.
Differential Revision: https://reviews.llvm.org/D64110
llvm-svn: 364992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.
The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.
rdar://44987528
Differential revision: https://reviews.llvm.org/D62825
llvm-svn: 364954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option behaves similarly to AlignConsecutiveDeclarations and
AlignConsecutiveAssignments, aligning the assignment of C/C++
preprocessor macros on consecutive lines.
I've worked in many projects (embedded, mostly) where header files full
of large, well-aligned "#define" blocks are a common pattern. We
normally avoid using clang-format on these files, since it ruins any
existing alignment in said blocks. This style option will align "simple"
PP macros (no parameters) and PP macros with parameter lists on
consecutive lines.
Related Bugzilla entry (thanks mcuddie):
https://llvm.org/bugs/show_bug.cgi?id=20637
Patch by Nick Renieris (VelocityRa)!
Differential Revision: https://reviews.llvm.org/D28462
llvm-svn: 364938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This revision allows users to specify the insertion of an included directive (at
the top of the file being rewritten) as part of a rewrite rule. These
directives are bundled with `RewriteRule` cases, so that different cases can
potentially result in different include actions.
Reviewers: ilya-biryukov, gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63892
llvm-svn: 364917
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hokein
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64063
llvm-svn: 364904
|
|
|
|
|
|
|
|
|
| |
Removes a vector reference that was added by D62998, since the
preexisting function parameter is sufficient.
Differential Revision: https://reviews.llvm.org/D64044
llvm-svn: 364895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Structural equivalence did not handle dependent template args properly
when the arg contained a DependentScopeDeclRefExpr.
Reviewers: a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62329
llvm-svn: 364889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
kmalloc is freed with kfree in the linux kernel. kmalloc support was
added in r204832, but kfree was not. Adding kfree fixes incorrectly
detected memory leaks.
Reviewers: NoQ, nickdesaulniers, dcoughlin, Szelethus
Reviewed By: NoQ, Szelethus
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64030
llvm-svn: 364875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to RVO the target region of a function that returns an object by
value isn't necessarily a temporary object region; it may be an
arbitrary memory region. In particular, it may be a field of a bigger
object.
Make sure we don't invalidate the bigger object when said function is
evaluated conservatively.
Differential Revision: https://reviews.llvm.org/D63968
llvm-svn: 364870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NonnullGlobalConstants checker models the rule "it doesn't make sense
to make a constant global pointer and initialize it to null"; it makes sure
that whatever it's initialized with is known to be non-null.
Ironically, annotating the type of the pointer as _Nonnull breaks the checker.
Fix handling of the _Nonnull annotation so that it was instead one more reason
to believe that the value is non-null.
Differential Revision: https://reviews.llvm.org/D63956
llvm-svn: 364869
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uses the new CDF_MaybeBuiltin flag to handle C library functions.
It's mostly an NFC/refactoring pass, but it does fix a bug in handling memset()
when it expands to __builtin___memset_chk() because the latter has
one more argument and memset() handling code was trying to match
the exact number of arguments. Now the code is deduplicated and there's
less room for mistakes.
Differential Revision: https://reviews.llvm.org/D62557
llvm-svn: 364868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When matching C standard library functions in the checker, it's easy to forget
that they are often implemented as macros that are expanded to builtins.
Such builtins would have a different name, so matching the callee identifier
would fail, or may sometimes have more arguments than expected, so matching
the exact number of arguments would fail, but this is fine as long as we have
all the arguments that we need in their respective places.
This patch adds a set of flags to the CallDescription class so that to handle
various special matching rules, and adds the first flag into this set,
which enables a more fuzzy matching for functions that
may be implemented as compiler builtins.
Differential Revision: https://reviews.llvm.org/D62556
llvm-svn: 364867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It encapsulates the procedure of figuring out whether a call event
corresponds to a function that's modeled by a checker.
Checker developers no longer need to worry about performance of
lookups into their own custom maps.
Add unittests - which finally test CallDescription itself as well.
Differential Revision: https://reviews.llvm.org/D62441
llvm-svn: 364866
|
|
|
|
|
|
| |
HeaderFilter -> HeaderFilterRegex
llvm-svn: 364837
|
|
|
|
|
|
|
|
| |
Previously, lambda captures were processed in the function called during
capturing the variables. It leads to the recursive functions calls and
may result in the compiler crash.
llvm-svn: 364820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now we store the errors for the Decls in the "to" context too. For
that, however, we have to put these errors in a shared state (among all
the ASTImporter objects which handle the same "to" context but different
"from" contexts).
After a series of imports from different "from" TUs we have a "to" context
which may have erroneous nodes in it. (Remember, the AST is immutable so
there is no way to delete a node once we had created it and we realized
the error later.) All these erroneous nodes are marked in
ASTImporterSharedState::ImportErrors. Clients of the ASTImporter may
use this as an input. E.g. the static analyzer engine may not try to
analyze a function if that is marked as erroneous (it can be queried via
ASTImporterSharedState::getImportDeclErrorIfAny()).
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62376
llvm-svn: 364785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLVM issues a warning if passed unknown target features. Neither I nor
@asb noticed this until after https://reviews.llvm.org/D63498 landed.
This patch stops passing the (unknown) "save-restore" target feature to
the LLVM backend, but continues to emit a warning if a driver asks for
`-msave-restore`. The default of assuming `-mno-save-restore` (and
emitting no warnings) remains.
Reviewers: asb
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, cfe-commits, asb
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64008
llvm-svn: 364777
|
|
|
|
| |
llvm-svn: 364774
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
During import of a specific Decl D, it may happen that some AST nodes
had already been created before we recognize an error. In this case we
signal back the error to the caller, but the "to" context remains
polluted with those nodes which had been created. Ideally, those nodes
should not had been created, but that time we did not know about the
error, the error happened later. Since the AST is immutable (most of
the cases we can't remove existing nodes) we choose to mark these nodes
as erroneous.
Here are the steps of the algorithm:
1) We keep track of the nodes which we visit during the import of D: See
ImportPathTy.
2) If a Decl is already imported and it is already on the import path
(we have a cycle) then we copy/store the relevant part of the import
path. We store these cycles for each Decl.
3) When we recognize an error during the import of D then we set up this
error to all Decls in the stored cycles for D and we clear the stored
cycles.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62375
llvm-svn: 364771
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
During analysis of one project we failed to import one
CXXDestructorDecl. But since we did not propagate the error in
importDeclContext we had a CXXRecordDecl without a destructor. Then the
analyzer engine had a CallEvent where the nonexistent dtor was requested
(crash).
Solution is to propagate the errors we have during importing a
DeclContext.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63603
llvm-svn: 364752
|
|
|
|
| |
llvm-svn: 364720
|
|
|
|
|
|
|
|
| |
Reviewed By: ziangwan
Differential Revision: https://reviews.llvm.org/D63822
llvm-svn: 364704
|
|
|
|
|
|
|
|
| |
This reverts commit ab2c0ed01edfec9a9402d03bdf8633b34b73f3a7.
See https://reviews.llvm.org/D63155
llvm-svn: 364692
|
|
|
|
|
|
|
|
|
| |
If the variable is used in the OpenMP region implicitly, we need to
check the data-sharing attributes for such variables and generate
implicit clauses for them. Patch improves analysis of such variables for
better handling of data-sharing rules.
llvm-svn: 364683
|
|
|
|
| |
llvm-svn: 364679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Selector::getIdentifierInfoForSlot` returns NULL if a slot has no
corresponding identifier. Add a boolean to the hash and a NULL check.
rdar://problem/51615164
Reviewers: rtrieu
Reviewed By: rtrieu
Subscribers: dexonsmith, cfe-commits, jkorous
Differential Revision: https://reviews.llvm.org/D63789
llvm-svn: 364664
|
|
|
|
|
|
|
|
|
| |
Fixed handling of the data-sharing attributes for static members when
requesting top most attribute. Previously, it might return the incorrect
attributes for static members if they were overriden in the outer
constructs.
llvm-svn: 364655
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the OpenMP 5.0 standard, the loop iteration variable in the associated
for-loop of a simd construct with just one associated for-loop may be
listed in a private, lastprivate, or linear clause with a linear-step
that is the increment of the associated for-loop. Also, the loop
teration variables in the associated for-loops of a simd construct with
multiple associated for-loops may be listed in a private or lastprivate
clause.
llvm-svn: 364650
|