2019-05-17 17:29:44 +08:00
|
|
|
// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ConfigDumper > %t 2>&1
|
2018-02-27 09:31:56 +08:00
|
|
|
// RUN: FileCheck --input-file=%t %s --match-full-lines
|
2012-10-02 02:28:19 +08:00
|
|
|
|
|
|
|
|
// CHECK: [config]
|
[analyzer] [NFC] PathDiagnostic: Create PathDiagnosticPopUpPiece
Summary:
This new piece is similar to our macro expansion printing in HTML reports:
On mouse-hover event it pops up on variables. Similar to note pieces it
supports `plist` diagnostics as well.
It is optional, on by default: `add-pop-up-notes=true`.
Extra: In HTML reports `background-color: LemonChiffon` was too light,
changed to `PaleGoldenRod`.
Reviewers: NoQ, alexfh
Reviewed By: NoQ
Subscribers: cfe-commits, gerazo, gsd, george.karpenkov, alexfh, xazax.hun,
baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho,
Szelethus, donat.nagy, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60670
llvm-svn: 362014
2019-05-30 03:21:59 +08:00
|
|
|
// CHECK-NEXT: add-pop-up-notes = true
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: aggressive-binary-operation-simplification = false
|
2019-05-17 17:29:44 +08:00
|
|
|
// CHECK-NEXT: alpha.clone.CloneChecker:IgnoredFilesPattern = ""
|
|
|
|
|
// CHECK-NEXT: alpha.clone.CloneChecker:MinimumCloneComplexity = 50
|
|
|
|
|
// CHECK-NEXT: alpha.clone.CloneChecker:ReportNormalClones = true
|
|
|
|
|
// CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtExec = 0x04
|
|
|
|
|
// CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtRead = 0x01
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: avoid-suppressing-null-argument-paths = false
|
|
|
|
|
// CHECK-NEXT: c++-allocator-inlining = true
|
|
|
|
|
// CHECK-NEXT: c++-container-inlining = false
|
|
|
|
|
// CHECK-NEXT: c++-inlining = destructors
|
|
|
|
|
// CHECK-NEXT: c++-shared_ptr-inlining = false
|
|
|
|
|
// CHECK-NEXT: c++-stdlib-inlining = true
|
|
|
|
|
// CHECK-NEXT: c++-temp-dtor-inlining = true
|
|
|
|
|
// CHECK-NEXT: c++-template-inlining = true
|
2013-03-29 08:09:28 +08:00
|
|
|
// CHECK-NEXT: cfg-conditional-static-initializers = true
|
2017-07-12 15:04:19 +08:00
|
|
|
// CHECK-NEXT: cfg-implicit-dtors = true
|
|
|
|
|
// CHECK-NEXT: cfg-lifetime = false
|
2017-08-19 19:19:16 +08:00
|
|
|
// CHECK-NEXT: cfg-loopexit = false
|
[CFG] Add extra context to C++ constructor statement elements.
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
2018-02-09 06:58:15 +08:00
|
|
|
// CHECK-NEXT: cfg-rich-constructors = true
|
2018-03-12 20:26:15 +08:00
|
|
|
// CHECK-NEXT: cfg-scopes = false
|
2018-03-02 02:53:13 +08:00
|
|
|
// CHECK-NEXT: cfg-temporary-dtors = true
|
2019-05-17 17:29:44 +08:00
|
|
|
// CHECK-NEXT: cplusplus.Move:WarnOn = KnownsAndLocals
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: crosscheck-with-z3 = false
|
|
|
|
|
// CHECK-NEXT: ctu-dir = ""
|
2019-07-08 20:37:10 +08:00
|
|
|
// CHECK-NEXT: ctu-import-threshold = 100
|
[analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions
Summary: This is just changing naming and documentation to be general about external definitions that can be imported for cross translation unit analysis. There is at least a plan to add VarDecls: D46421
Reviewers: NoQ, xazax.hun, martong, a.sidorin, george.karpenkov, serge-sans-paille
Reviewed By: xazax.hun, martong
Subscribers: mgorny, whisperity, baloghadamsoftware, szepet, rnkovacs, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D56441
llvm-svn: 350852
2019-01-11 01:44:04 +08:00
|
|
|
// CHECK-NEXT: ctu-index-name = externalDefMap.txt
|
2019-05-17 17:29:44 +08:00
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:* = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:Bind = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:EndFunction = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:LiveSymbols = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:NewAllocator = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PostCall = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PostStmtArraySubscriptExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PostStmtCXXNewExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PostStmtCastExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PostStmtOffsetOfExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PreCall = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PreStmtArraySubscriptExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PreStmtCXXNewExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PreStmtCastExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:PreStmtOffsetOfExpr = false
|
|
|
|
|
// CHECK-NEXT: debug.AnalysisOrder:RegionChanges = false
|
[CTU] Add DisplayCTUProgress analyzer switch
Summary:
With a new switch we may be able to print to stderr if a new TU is being loaded
during CTU. This is very important for higher level scripts (like CodeChecker)
to be able to parse this output so they can create e.g. a zip file in case of
a Clang crash which contains all the related TU files.
Reviewers: xazax.hun, Szelethus, a_sidorin, george.karpenkov
Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp,
Differential Revision: https://reviews.llvm.org/D55135
llvm-svn: 348594
2018-12-07 22:56:02 +08:00
|
|
|
// CHECK-NEXT: display-ctu-progress = false
|
2018-08-30 04:29:17 +08:00
|
|
|
// CHECK-NEXT: eagerly-assume = true
|
2018-06-28 08:04:54 +08:00
|
|
|
// CHECK-NEXT: elide-constructors = true
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: expand-macros = false
|
|
|
|
|
// CHECK-NEXT: experimental-enable-naive-ctu-analysis = false
|
2018-02-27 09:31:56 +08:00
|
|
|
// CHECK-NEXT: exploration_strategy = unexplored_first_queue
|
2012-10-02 02:28:19 +08:00
|
|
|
// CHECK-NEXT: faux-bodies = true
|
2012-10-24 07:59:05 +08:00
|
|
|
// CHECK-NEXT: graph-trim-interval = 1000
|
2015-09-12 04:14:05 +08:00
|
|
|
// CHECK-NEXT: inline-lambdas = true
|
2013-01-25 07:15:30 +08:00
|
|
|
// CHECK-NEXT: ipa = dynamic-bifurcate
|
2012-10-03 04:31:56 +08:00
|
|
|
// CHECK-NEXT: ipa-always-inline-size = 3
|
2017-06-21 19:29:35 +08:00
|
|
|
// CHECK-NEXT: max-inlinable-size = 100
|
|
|
|
|
// CHECK-NEXT: max-nodes = 225000
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: max-symbol-complexity = 35
|
2012-12-18 04:08:51 +08:00
|
|
|
// CHECK-NEXT: max-times-inline-large = 32
|
2015-09-12 04:14:05 +08:00
|
|
|
// CHECK-NEXT: min-cfg-size-treat-functions-as-large = 14
|
2013-01-25 07:15:34 +08:00
|
|
|
// CHECK-NEXT: mode = deep
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: model-path = ""
|
|
|
|
|
// CHECK-NEXT: notes-as-events = false
|
2019-05-17 17:29:44 +08:00
|
|
|
// CHECK-NEXT: nullability:NoDiagnoseCallsToSystemHeaders = false
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: objc-inlining = true
|
2019-05-17 17:29:44 +08:00
|
|
|
// CHECK-NEXT: optin.cplusplus.UninitializedObject:CheckPointeeInitialization = false
|
|
|
|
|
// CHECK-NEXT: optin.cplusplus.UninitializedObject:IgnoreGuardedFields = false
|
|
|
|
|
// CHECK-NEXT: optin.cplusplus.UninitializedObject:IgnoreRecordsWithField = ""
|
|
|
|
|
// CHECK-NEXT: optin.cplusplus.UninitializedObject:NotesAsWarnings = false
|
|
|
|
|
// CHECK-NEXT: optin.cplusplus.UninitializedObject:Pedantic = false
|
|
|
|
|
// CHECK-NEXT: optin.cplusplus.VirtualCall:PureOnly = false
|
|
|
|
|
// CHECK-NEXT: optin.osx.cocoa.localizability.NonLocalizedStringChecker:AggressiveReport = false
|
|
|
|
|
// CHECK-NEXT: optin.performance.Padding:AllowedPad = 24
|
|
|
|
|
// CHECK-NEXT: osx.NumberObjectConversion:Pedantic = false
|
|
|
|
|
// CHECK-NEXT: osx.cocoa.RetainCount:CheckOSObject = true
|
|
|
|
|
// CHECK-NEXT: osx.cocoa.RetainCount:TrackNSCFStartParam = false
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: prune-paths = true
|
[analyzer] "Force" LazyCompoundVals on bind when they are simple enough.
The analyzer uses LazyCompoundVals to represent rvalues of aggregate types,
most importantly structs and arrays. This allows us to efficiently copy
around an entire struct, rather than doing a memberwise load every time a
struct rvalue is encountered. This can also keep memory usage down by
allowing several structs to "share" the same snapshotted bindings.
However, /lookup/ through LazyCompoundVals can be expensive, especially
since they can end up chaining back to the original value. While we try
to reuse LazyCompoundVals whenever it's safe, and cache information about
this transitivity, the fact is it's sometimes just not a good idea to
perpetuate LazyCompoundVals -- the tradeoffs just aren't worth it.
This commit changes RegionStore so that binding a LazyCompoundVal to struct
will do a memberwise copy if the struct is simple enough. Today's definition
of "simple enough" is "up to N scalar members" (see below), but that could
easily be changed in the future. This is enough to bring the test case in
PR15697 back down to a manageable analysis time (within 20% of its original
time, in an unfair test where the new analyzer is not compiled with LTO).
The actual value of "N" is controlled by a new -analyzer-config option,
'region-store-small-struct-limit'. It defaults to "2", meaning structs with
zero, one, or two scalar members will be considered "simple enough" for
this code path.
It's worth noting that a more straightforward implementation would do this
on load, not on bind, and make use of the structure we already have for this:
CompoundVal. A long time ago, this was actually how RegionStore modeled
aggregate-to-aggregate copies, but today it's only used for compound literals.
Unfortunately, it seems that we've special-cased LazyCompoundVal in certain
places (such as liveness checks) but failed to similarly special-case
CompoundVal in all of them. Until we're confident that CompoundVal is
handled properly everywhere, this solution is safer, since the entire
optimization is just an implementation detail of RegionStore.
<rdar://problem/13599304>
llvm-svn: 179767
2013-04-19 00:33:46 +08:00
|
|
|
// CHECK-NEXT: region-store-small-struct-limit = 2
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: report-in-main-source-file = false
|
2018-02-10 09:49:20 +08:00
|
|
|
// CHECK-NEXT: serialize-stats = false
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
// CHECK-NEXT: stable-report-filename = false
|
|
|
|
|
// CHECK-NEXT: suppress-c++-stdlib = true
|
|
|
|
|
// CHECK-NEXT: suppress-inlined-defensive-checks = true
|
|
|
|
|
// CHECK-NEXT: suppress-null-return-paths = true
|
[analyzer] Track terminator conditions on which a tracked expression depends
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
2019-07-05 21:29:54 +08:00
|
|
|
// CHECK-NEXT: track-conditions = false
|
2019-07-05 22:00:08 +08:00
|
|
|
// CHECK-NEXT: track-conditions-debug = false
|
2019-05-17 17:29:44 +08:00
|
|
|
// CHECK-NEXT: unix.DynamicMemoryModeling:Optimistic = false
|
2017-07-26 03:23:23 +08:00
|
|
|
// CHECK-NEXT: unroll-loops = false
|
2015-10-30 23:23:57 +08:00
|
|
|
// CHECK-NEXT: widen-loops = false
|
2012-10-02 02:28:19 +08:00
|
|
|
// CHECK-NEXT: [stats]
|
2019-07-08 20:37:10 +08:00
|
|
|
// CHECK-NEXT: num-entries = 88
|