SValBuilder tries to constant-fold symbols in the left-hand side of the symbolic
expression whenever it fails to evaluate the expression directly. However, it
only constant-folds them when they are atomic expressions, not when they are
complicated expressions themselves. This patch adds recursive constant-folding
to the left-hand side subexpression (there's a lack of symmetry because we're
trying to have symbols on the left and constants on the right). As an example,
we'd now be able to handle operations similar to "$x + 1 < $y", when $x is
constrained to a constant.
rdar://problem/31354676
Differential Revision: https://reviews.llvm.org/D31886
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300178 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The basic constraint solver was dropped in rL162384, leaving the range constraint solver as the default and only constraint solver. Explicitly specifying it is unnecessary, and makes it difficult to test with other solver backends.
Reviewers: zaks.anna, dcoughlin
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26694
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288372 91177308-0d34-0410-b5e6-96231b3b80d8
In C, comparisons between signed and unsigned numbers are always done in
unsigned-space. Thus, we should know that "i >= 0U" is always true, even
if 'i' is signed. Similarly, "u >= 0" is also always true, even though '0'
is signed.
Part of <rdar://problem/13239003> (false positives related to std::vector)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177806 91177308-0d34-0410-b5e6-96231b3b80d8
type conversion between integers. This allows the warning to be more accurate.
Also, turned the warning off in an analyzer test. The relavent test cases
are covered by the tests in Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167992 91177308-0d34-0410-b5e6-96231b3b80d8
integral expression have the obvious result.
Patch reviewed by John McCall off line.
// rdar://12202422
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164143 91177308-0d34-0410-b5e6-96231b3b80d8
As part of this change, I discovered that a few of our tests were not testing
the RangeConstraintManager. Luckily all of those passed when I moved them
over to use that constraint manager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162384 91177308-0d34-0410-b5e6-96231b3b80d8
This involves keeping track of three separate types: the symbol type, the
adjustment type, and the comparison type. For example, in "$x + 5 > 0ULL",
if the type of $x is 'signed char', the adjustment type is 'int' and the
comparison type is 'unsigned long long'. Most of the time these three types
will be the same, but we should still do the right thing when the
comparison value is out of range, and wraparound should be calculated in
the adjustment type.
This also re-disables an out-of-bounds test; we were extracting the symbol
from non-additive SymIntExprs, but then throwing away the integer.
Sorry for the large patch; both the basic and range constraint managers needed
to be updated together, since they share code in SimpleConstraintManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156361 91177308-0d34-0410-b5e6-96231b3b80d8
George Karpenkov