the index when the value evaluation isn't powerful enough. By creating ElementRegions with
UnknownVals as the index, this gives the false impression that they are the same element, when
they really aren't. This becomes really problematic when deriving symbols from these regions
(e.g., those representing the initial value of the index), since two different indices will
get the same symbol for their binding.
This fixes an issue with the idempotent operations checker that would cause two indices that
are clearly not the same to make it appear as if they always had the same value.
Fixes <rdar://problem/8431728>.
llvm-svn: 113920
this fixes all analyser test failures in my gcc34-based
environment
how the cast result could bind to the non-const ref is
somewhat mysterious and remains to be investigated; to
avoid similar miscompilations (by gcc34 only?)
llvm-svn: 113480
The end result is now we eagarly constant-fold symbols in the analyzer that are perfectly constrained
to be a constant value. This allows us to recover some path-sensitivity in some cases by lowering
the required level of reasoning power needed to evaluate some expressions.
The net win from this change is that the false positive in PR 8015 is fixed, and we also
find more idempotent operations bugs.
We do, however, regress with the BugReporterVisitors, which need to be modified to understand
this constant folding (and look past it). This causes some diagnostic regressions in plist-output.m
which will get addressed in a future patch. plist-output.m is now marked XFAIL, while
plist-output-alternate.m now tests that the plist output is working, but with the suboptimal
diagnostics. This second test file will eventually be removed.
llvm-svn: 113477
- Created private class CFGReachabilityAnalysis, which provides cached reachability lookups in the CFG
- Simplified PathWasCompletelyAnalyzed to use the new reachability class
- Added getLastRelevantNodes function for future use with path displaying in BugReporter
llvm-svn: 113465
should probably be removed if it has no purpose, but I just #if'd it out
in case it's usefulIdempotentOperationChecker::isTruncationExtensionAssignment
should probably be removed if it has no purpose, but I just #if'd it out
in case it's useful
llvm-svn: 112949
- SourceRange highlighting is only given for the relevant side of the operator (assignments give both)
- Added PostVisitBinaryOperator hook to retrieve the ExplodedNode for an operator
- Added a BugReporterVisitor to display the last store to every VarDecl in a Stmt
- Changed bug reporting to use the new BugReporterVisitor
llvm-svn: 112839
- Fixed a regression where assigning '0' would be reported
- Changed the way self assignments are filtered to allow constant testing
- Added a test case for assign ops
- Fixed one test case where a function pointer was not considered constant
- Fixed test cases relating to 0 assignment
llvm-svn: 112501
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
Ted Kremenek