The motivation here is a "clever" implementation of strncmp(), which peels the first few comparisons via chained conditional expressions which ensure that the input arrays are known at compile time to be sufficiently large.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146430 91177308-0d34-0410-b5e6-96231b3b80d8
setting the is_zero_undef flag appropriately to true as that matches the
semantics of these GCC builtins.
This is the Clang side of r146357 in LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146358 91177308-0d34-0410-b5e6-96231b3b80d8
We are now often generating expressions even if the solver is not known to be able to simplify it. This is another cleanup of the existing code, where the rest of the analyzer and checkers should not base their logic on knowing ahead of the time what the solver can reason about.
In this case, CStringChecker is performing a check for overflow of 'left+right' operation. The overflow can be checked with either 'maxVal-left' or 'maxVal-right'. Previously, the decision was based on whether the expresion evaluated to undef or not. With this patch, we check if one of the arguments is a constant, in which case we know that 'maxVal-const' is easily simplified. (Another option is to use canReasonAbout() method of the solver here, however, it's currently is protected.)
This patch also contains 2 small bug fixes:
- swap the order of operators inside SValBuilder::makeGenericVal.
- handle a case when AddeVal is unknown in GenericTaintChecker::getPointedToSymbol.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146343 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a bug in SimpleSValBuilder, where we should swap lhs and rhs when calling generateUnknownVal(), - the function which creates symbolic expressions when data is tainted. The issue is not visible when we only create the expressions for taint since all expressions are commutative from taint perspective.
Refactor SymExpr::symbol_iterator::expand() to use a switch instead of a chain of ifs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146336 91177308-0d34-0410-b5e6-96231b3b80d8
compilation of some translation units of SPEC's 445.gobmk by ~4%, and does not
seem to cause a measurable slowdown in other cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146306 91177308-0d34-0410-b5e6-96231b3b80d8
template instantiation), and that expression might produce a
temporary, invoke MaybeBindToTemporary. Otherwise, we forget to
destroy objects, release objects, etc. Fixes <rdar://problem/10531073>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146301 91177308-0d34-0410-b5e6-96231b3b80d8
-ffinite-math-only.
- No test case yet, I don't know how to construct a situation where this
matters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146297 91177308-0d34-0410-b5e6-96231b3b80d8
whether an expression is a (core) constant expression as a side-effect of
evaluation. This takes us from accepting far too few expressions as ICEs to
accepting slightly too many -- fixes for the remaining cases are coming next.
The diagnostics produced when an expression is found to be non-constant are
currently quite poor (with generic wording but reasonable source locations),
and will be improved in subsequent commits.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146289 91177308-0d34-0410-b5e6-96231b3b80d8
".framework/" in the path name, because it could be ".framework\" on
Windows. This whole function needs to be rewritten with PathV2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146261 91177308-0d34-0410-b5e6-96231b3b80d8
having it evaluate them. No change in functionality, but a speed up of about 5%
on some translation units in SPEC 445.gobmk.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146248 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian
Eli Friedman
Chad Rosier
Matt Beaumont-Gay
Tony Linthicum
Richard Smith
Douglas Gregor
Hans Wennborg
Chandler Carruth
David Blaikie
Anna Zaks
Benjamin Kramer
NAKAMURA Takumi
Argyrios Kyrtzidis
Daniel Dunbar
Ted Kremenek