Nodes which have only one predecessor and only one successor can not
always be hidden, even if all states are the same.
An additional condition is needed: the predecessor may have only one successor.
This can be seen on this example:
```
A
/ \
B C
\ /
D
```
Nodes B and C can not be hidden even if all nodes in the graph have the
same state.
Differential Revision: https://reviews.llvm.org/D53735
llvm-svn: 345341
Previously, OSDynamicCast was modeled as an identity.
This is not correct: the output of OSDynamicCast may be zero even if the
input was not zero (if the class is not of desired type), and thus the
modeling led to false positives.
Instead, we are doing eager state split:
in one branch, the returned value is identical to the input parameter,
and in the other branch, the returned value is zero.
This patch required a substantial refactoring of canEval infrastructure,
as now it can return different function summaries, and not just true/false.
rdar://45497400
Differential Revision: https://reviews.llvm.org/D53624
llvm-svn: 345338
Summary:
This patch moves the last method in `Z3ConstraintManager` to `SMTConstraintManager`: `canReasonAbout()`.
The `canReasonAbout()` method checks if a given `SVal` can be encoded in SMT. I've added a new method to the SMT API to return true if a solver can encode floating-point arithmetics and it was enough to make `canReasonAbout()` solver independent.
As an annoying side-effect, `Z3ConstraintManager` is pretty empty now and only (1) creates the Z3 solver object by calling `CreateZ3Solver()` and (2) instantiates `SMTConstraintManager`. Maybe we can get rid of this class altogether in the future: a `CreateSMTConstraintManager()` method that does (1) and (2) and returns the constraint manager object?
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: mehdi_amini, xazax.hun, szepet, a.sidorin, dexonsmith, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53694
llvm-svn: 345284
Summary:
Getting an `APSInt` from the model always returned an unsigned integer because of the unused parameter.
This was not breaking any test case because no code relies on the actual value of the integer returned here, but rather it is only used to check if a symbol has more than one solution in `getSymVal`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53637
llvm-svn: 345283
trackNullOrUndefValue is a long and confusing name,
and it does not actually reflect what the function is doing.
Give a function a new name, with a relatively clear semantics.
Also remove some dead code.
Differential Revision: https://reviews.llvm.org/D52758
llvm-svn: 345064
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split
the casting logic up into smaller patches. This contains the code for casting
from fixed point types to boolean types.
Differential Revision: https://reviews.llvm.org/D53308
llvm-svn: 345063
I'm in the process of refactoring AnalyzerOptions. The main motivation behind
here is to emit warnings if an invalid -analyzer-config option is given from the
command line, and be able to list them all.
This first NFC patch contains small modifications to make AnalyzerOptions.cpp a
little more consistent.
Differential Revision: https://reviews.llvm.org/D53274
llvm-svn: 344870
The GDMIndex functions return a pointer that's used as a key for looking up
data, but addresses of local statics defined in header files aren't the same
across shared library boundaries and the result is that analyzer plugins
can't access this data.
Event types are uniqued by using the addresses of a local static defined
in a header files, but it isn't the same across shared library boundaries
and plugins can't currently handle ImplicitNullDerefEvents.
Patches by Joe Ranieri!
Differential Revision: https://reviews.llvm.org/D52905
Differential Revision: https://reviews.llvm.org/D52906
llvm-svn: 344823
In C++17, when class C has large alignment value, a special case of
overload resolution rule kicks in for expression new C that causes the aligned
version of operator new() to be called. The aligned new has two arguments:
size and alignment. However, the new-expression has only one "argument":
the construct-expression for C(). This causes a false positive in
core.CallAndMessage's check for matching number of arguments and number
of parameters.
Update CXXAllocatorCall, which is a CallEvent sub-class for operator new calls
within new-expressions, so that the number of arguments always matched
the number of parameters.
rdar://problem/44738501
Differential Revision: https://reviews.llvm.org/D52957
llvm-svn: 344539
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to
split them up. This contains the code for casting between fixed point types
and other fixed point types.
The method for converting between fixed point types is based off the convert()
method in APFixedPoint.
Differential Revision: https://reviews.llvm.org/D50616
llvm-svn: 344530
Summary:
Enhanced support for Z3 in the cmake configuration of clang; now it is possible to specify any arbitrary Z3 install prefix (CLANG_ANALYZER_Z3_PREFIX) to cmake with lib (or bin) and include folders. Before the patch only in cmake default locations
were searched (https://cmake.org/cmake/help/v3.4/command/find_path.html).
Specifying any CLANG_ANALYZER_Z3_PREFIX will force also CLANG_ANALYZER_BUILD_Z3 to ON.
Removed also Z3 4.5 version requirement since it was not checked, and now Clang works with Z3 4.7
Reviewers: NoQ, george.karpenkov, mikhail.ramalho
Reviewed By: george.karpenkov
Subscribers: rnkovacs, NoQ, esteffin, george.karpenkov, delcypher, ddcc, mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50818
llvm-svn: 344464
Doesn't do much despite sounding quite bad, but fixes an exotic test case where
liveness of a nonloc::LocAsInteger array index is now evaluated correctly.
Differential Revision: https://reviews.llvm.org/D52667
llvm-svn: 343631
I intend to add a new flag macro-expnasions-as-events, and unfortunately
I'll only be able to convert the macro piece into an event one once I'm
about to emit it, due to the lack of an avaible Preprocessor object in
the BugReporter.
Differential Revision: https://reviews.llvm.org/D52787
llvm-svn: 343620
Summary:
Several improvements in preparation for the new backends.
Refactoring:
- Removed duplicated methods `fromBoolean`, `fromAPSInt`, `fromInt` and `fromAPFloat`. The methods `mkBoolean`, `mkBitvector` and `mkFloat` are now used instead.
- The names of the functions that convert BVs to FPs were swapped (`mkSBVtoFP`, `mkUBVtoFP`, `mkFPtoSBV`, `mkFPtoUBV`).
- Added a couple of comments in function calls.
Crosscheck encoding:
- Changed how constraints are encoded in the refutation manager so it doesn't start with (false OR ...). This change introduces one duplicated line (see file `BugReporterVisitors.cpp`, the `SMTConv::getRangeExpr is called twice, so I can remove this change if the duplication is a problem.
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D52365
llvm-svn: 343581
This is patch is a preparation for the proposed inclusion of macro expansions in the plist output.
Differential Revision: https://reviews.llvm.org/D52735
llvm-svn: 343511
Dumping graphs instead of opening them is often very useful,
e.g. for transfer or converting to SVG.
Basic sanity check for generated exploded graphs.
Differential Revision: https://reviews.llvm.org/D52637
llvm-svn: 343352
Commit r340984 causes a crash when a pointer to a completely unrelated type
UnrelatedT (eg., opaque struct pattern) is being casted from base class BaseT to
derived class DerivedT, which results in an ill-formed region
Derived{SymRegion{$<UnrelatedT x>}, DerivedT}.
Differential Revision: https://reviews.llvm.org/D52189
llvm-svn: 343051
Combine the two constructor overrides into a single ArrayRef constructor
to allow easier brace initializations and simplify how the respective field
is used internally.
Differential Revision: https://reviews.llvm.org/D51390
llvm-svn: 343037
When a checker maintains a program state trait that isn't a simple list/set/map, but is a combination of multiple lists/sets/maps (eg., a multimap - which may be implemented as a map from something to set of something), ProgramStateManager only contains the factory for the trait itself. All auxiliary lists/sets/maps need a factory to be provided by the checker, which is annoying.
So far two checkers wanted a multimap, and both decided to trick the
ProgramStateManager into keeping the auxiliary factory within itself
by pretending that it's some sort of trait they're interested in,
but then never using this trait but only using the factory.
Make this trick legal. Define a convenient macro.
One thing that becomes apparent once all pieces are put together is that
these two checkers are in fact using the same factory, because the type that
identifies it, ImmutableMap<const MemRegion *, ImmutableSet<SymbolRef>>,
is the same. This situation is different from two checkers registering similar
primitive traits.
Differential Revision: https://reviews.llvm.org/D51388
llvm-svn: 343035
This patch is a band-aid. A proper solution would be too change
trackNullOrUndefValue to only try to dereference the pointer when it is
relevant to the problem.
Differential Revision: https://reviews.llvm.org/D52435
llvm-svn: 342920
If the non-sink report is generated at the exit node, it will be
suppressed by the current functionality in isInevitablySinking, as it
only checks the successors of the block, but not the block itself.
The bug shows up in RetainCountChecker checks.
Differential Revision: https://reviews.llvm.org/D52284
llvm-svn: 342766
Fixes a number of issues:
- Global variables are not used for communication
- Trait should be defined on a graph, not on a node
- Defining the trait on a graph allows us to use a correct allocator,
no longer crashing while printing trimmed graphs
Differential Revision: https://reviews.llvm.org/D52183
llvm-svn: 342413
Those are not created in the allocator.
Since they are created fairly rarely, a counter overhead should not
affect the memory consumption.
Differential Revision: https://reviews.llvm.org/D51827
llvm-svn: 342314
George Karpenkov