@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
@@ -212,6 +212,25 @@ typedef llvm::ImmutableMap
REGISTER_TRAIT_WITH_PROGRAMSTATE(PendingArrayDestruction,
PendingArrayDestructionMap)
+// This trait is used to heuristically filter out results produced from
+// execution paths that took "weak"
@@ -323,12 +342,13 @@ class ExprEngine {
/// ProcessBranch - Called by CoreEngine. Used to generate successor
/// nodes by processing the 'effects' of a branch condition.
- void processBranch(const Stmt *Condition,
- NodeBuilderContext& BuilderCtx,
-
@@ -583,11 +603,11 @@ class ExprEngine {
ExplodedNode *Pred,
ExplodedNodeSet &Dst);
- /// evalEagerlyAssumeBinOpBifurcation - Given the nodes in 'Src', eagerly
assume symbolic
- /// expressions of the form 'x
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -697,6 +697,11 @@ void ArrayBoundCheckerV2::reportOOB(CheckerContext &C,
ProgramStateRef ErrorState, Messages Msgs,
NonLoc Offset, std::optional
Extent,
bool IsTaintB
@@ -212,6 +212,25 @@ typedef llvm::ImmutableMap
REGISTER_TRAIT_WITH_PROGRAMSTATE(PendingArrayDestruction,
PendingArrayDestructionMap)
+// This trait is used to heuristically filter out results produced from
+// execution paths that took "weak"
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
@@ -3776,6 +3829,11 @@ void
ExprEngine::evalEagerlyAssumeBinOpBifurcation(ExplodedNodeSet &Dst,
ProgramStateRef StateTrue, StateFalse;
std::tie(StateTrue, StateFalse) = state->assume(*SEV);
+ if (StateTrue && StateFalse) {
+StateTrue = StateTrue->set(
@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
NagyDonat wrote:
> If I understand it correctly, we want to use (very likely) incorrect
> assumptions to suppress false positives produced by an alpha checker, which
> receives otherwise wrong assumptions. [...] I think the correct solution to
> this problem is to investigate why the specific
@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
@@ -121,6 +121,25 @@ struct EvalCallOptions {
EvalCallOptions() {}
};
+/// Simple control flow statements like `if` only produce a single state split,
+/// so the fact that they are included in the source code implies that both
+/// branches are possible (at least under some
@@ -121,6 +121,25 @@ struct EvalCallOptions {
EvalCallOptions() {}
};
+/// Simple control flow statements like `if` only produce a single state split,
+/// so the fact that they are included in the source code implies that both
+/// branches are possible (at least under some
@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
@@ -2808,27 +2825,63 @@ void ExprEngine::processBranch(const Stmt *Condition,
std::tie(StTrue, StFalse) = *KnownCondValueAssumption;
else {
assert(!isa(Condition));
+ // TODO: instead of this shortcut perhaps it would be better to "rejoin"
+ // the com
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/109804
From 23b27377e556085054621f27d97059618b416695 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 23 Sep 2024 15:42:20 +0200
Subject: [PATCH 1/7] [analyzer] Suppress out of bounds reports a
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/109804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
@isuckatcs If I am not mistaken, I reacted to every comment in your first
review.
I'm sorry for the salty initial reactions -- after thinking about this topic
for months, I ended up feeling that everything is _so obvious_, while in fact
it's a really complicated topic and per
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/109804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -63,11 +62,39 @@ void FixedAddressChecker::checkPreStmt(const BinaryOperator
*B,
"Using a fixed address is not portable because that address will "
"probably not be valid in all environments or platforms.";
auto R = std::make_unique(BT, Msg, N);
-R->
https://github.com/NagyDonat commented:
Nice improvement, thanks for the patch! I read the code but I don't have
anything to mention which isn't covered by the review of @steakhal .
https://github.com/llvm/llvm-project/pull/110977
___
cfe-commits mail
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/113906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
Thanks for the information!
I'll merge this now and I might create a followup commit to remove the rest of
`TraversalChecker.cpp` later.
https://github.com/llvm/llvm-project/pull/113906
___
cfe-commits mailing list
cfe-commits@lists.
NagyDonat wrote:
Thanks for handling this issue!
My quick first impression is that I'm satisfied with your changes. However, I'm
a bit confused because as far as I see, the empty struct is _unable to_
transfer any attacker-controlled data, and therefore I don't know what does it
mean that it'
NagyDonat wrote:
Thanks for the explanation -- code example reduction friendliness is a good
point that I didn't think about. Based on this, I support keeping that commit,
but perhaps add some remarks (in comments or the commit message, wherever you
think it's well-placed) that mentions code r
NagyDonat wrote:
@balazske As we discussed in person, I think you switch to detecting
_dereference_ of fixed addresses (instead of extending the current "store of
fixed address in pointer value" model e.g. by the commit under review).
I think you should briefly look at DereferenceChecker and c
NagyDonat wrote:
> The second is, how can we end up with such subregions. I think the only way
> is by field regions. If we had something that I missed, the assert would
> catch it.
Quick guesses: can we form a base or derived object subregion from them? Is
there some hacky pathway where we c
NagyDonat wrote:
I didn't run an analysis yet, because I was convinced about the correctness of
this change based on an understanding of the source code (and the fact that the
lit tests pass). However, I started a test run now to double-check this. I'll
merge this commit if it reveals no discr
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/117898
Previously `BranchNodeBuilder` had a machinery to mark the two possible
branches (true, false) as infeasible, but this was completely useless in
practice, because the `BranchNodeBuilder` objects where short-l
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/116840
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
The change LGTM and I'm happy to hear that you're improving the handling of
compound values. I hope that these foundational improvements will help further
development of checkers that deal with structured data. (Perhaps even the
iterator
@@ -86,6 +86,8 @@ def __init__(self, json_pp):
if json_pp["location"] is not None
else None
)
+elif self.kind == "CallEnter":
+self.callee_decl = json_pp["callee_decl"] if "callee_decl" in
json_pp else "None"
https://github.com/NagyDonat approved this pull request.
LGTM, with one minor simplification suggestion marked in an inline comment.
Disclaimer: I don't use this exploded-graph-rewriter tool, but the change seems
to be straightforward and useful.
https://github.com/llvm/llvm-project/pull/11622
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/116225
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
I didn't systematically analyze all the small details of this commit, but
overall it looks good to me.
https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@l
https://github.com/NagyDonat commented:
Do I understand it correctly that this deficiency affects the standalone Z3
analysis mode (as opposed to the "Z3 refutation" where the analysis is
performed with the native range-based constraint manager, and then the results
are validated with Z3 to dis
@@ -0,0 +1,16 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify
%s \
+// RUN: -analyzer-constraints=z3
+
+// REQUIRES: Z3
+//
+// This LIT covers a crash associated with this test.
+// The expectation is to not crash!
NagyDonat
@@ -0,0 +1,16 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify
%s \
+// RUN: -analyzer-constraints=z3
+
+// REQUIRES: Z3
+//
+// This LIT covers a crash associated with this test.
+// The expectation is to not crash!
+//
+
+long a;
+void b() {
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/108900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/108900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/108900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
The commit which introduced the new Z3 timeout logic
(https://github.com/llvm/llvm-project/pull/97298) was landed with my approval,
but since then I realized that this was a mistake -- in particular the concrete
fine-tuned default values
NagyDonat wrote:
I tested this commit on several open source projects, and as there were no
changes in the results, I'm merging this PR now.
https://github.com/llvm/llvm-project/pull/117898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/117898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, as we discussed earlier.
https://github.com/llvm/llvm-project/pull/115916
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2609,9 +2611,42 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(Store S,
+const MemRegion *BaseR) const {
+ assert(BaseR
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/115917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2609,9 +2611,42 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(Store S,
+const MemRegion *BaseR) const {
+ assert(BaseR
https://github.com/NagyDonat approved this pull request.
Overall LGTM, I added a few minor inline comments, but they are not blocking
issues.
https://github.com/llvm/llvm-project/pull/115917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
@@ -2609,9 +2611,42 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(Store S,
+const MemRegion *BaseR) const {
+ assert(BaseR
@@ -2605,9 +2608,43 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(nonloc::LazyCompoundVal LCV) const
{
+ const MemRegion *BaseR = LCV.getRegion();
+
+ // We only ha
@@ -2609,9 +2611,42 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(Store S,
+const MemRegion *BaseR) const {
+ assert(BaseR
@@ -2609,9 +2611,42 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(Store S,
+const MemRegion *BaseR) const {
+ assert(BaseR
https://github.com/NagyDonat approved this pull request.
LGTM, clean little patch, I don't have anything to say here.
https://github.com/llvm/llvm-project/pull/115918
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for the updates.
https://github.com/llvm/llvm-project/pull/113899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
I'm not familiar with these files, but the change seems to be harmless enough...
Let's hope that it doesn't cause any weird bugs.
https://github.com/llvm/llvm-project/pull/117481
___
cfe-commits
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
NagyDonat wrote:
> I adjusted the first commit message to highlight my answer to these
> questions. I hope that's clear enough.
Ok, I'd say that this explanation is _good enough_ to claim that "this change
may be helpful" -- which is sufficient to merge this change, because it's
conservative,
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -77,16 +80,32 @@ void
Z3CrosscheckVisitor::finalizeVisitor(BugReporterContext &BRC,
RefutationSolver->addConstraint(SMTConstraints);
}
- // And check for satisfiability
- llvm::TimeRecord Start = llvm::TimeRecord::getCurrentTime(/*Start=*/true);
- std::optional Is
https://github.com/NagyDonat commented:
I'm really grateful that you implemented my request about defining this option
as a positive value; especially considering that it ended up being more work
than what I expected. (I guessed that we must already had precedent(s) for
positive (or at least o
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for the updates!
If the updated test passes, feel free to merge it.
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
https://github.com/NagyDonat approved this pull request.
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -224,6 +224,8 @@ class SymbolMetadata : public SymbolData {
const Stmt *S;
QualType T;
const LocationContext *LCtx;
+ /// Count can be used to differentiate regions corresponding to
+ /// different loop iterations, thus, making the symbol path-dependent.
https://github.com/NagyDonat commented:
I'm grateful for this code quality improvement, it's nice to see that you got
rid of 180 lines of boilerplate :smile:
I have one minor inline suggestion that it would be nice to document the
purpose of this new template method; but otherwise the change i
@@ -525,14 +527,14 @@ class SymbolManager {
static bool canSymbolicate(QualType T);
- /// Make a unique symbol for MemRegion R according to its kind.
- const SymbolRegionValue* getRegionValueSymbol(const TypedValueRegion* R);
+ template const T *get(Args &&...args);
---
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, straightforward improvement.
https://github.com/llvm/llvm-project/pull/121910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
@@ -525,14 +527,14 @@ class SymbolManager {
static bool canSymbolicate(QualType T);
- /// Make a unique symbol for MemRegion R according to its kind.
- const SymbolRegionValue* getRegionValueSymbol(const TypedValueRegion* R);
+ template const T *get(Args &&...args);
---
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
My first idea is a "down to earth", not so modern, but more backwards
compatible approach:
- the analyzer option type stays plain `unsigned`;
- we introduce a new method called `validateAnalyzerOptionValues()` or
something similar;
- in this method we specify that `if (Z3Crossc
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121759
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1389,6 +1389,68 @@ Query for this attribute with
``__has_attribute(overloadable)``.
}];
}
+def OwnershipDocs : Documentation {
+ let Heading = "ownership_holds, ownership_returns, ownership_takes (Clang "
+"Static Analyzer)";
+ let Category = DocCatFun
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for adding this documentation!
I added an inline suggestion that -- hopefully -- clarifies the differences
between held and taken memory areas; but the original is also completely OK.
Feel free to ignore or tweak my suggesti
NagyDonat wrote:
> My preference would be to not have NFC tags for off by default features.
OK, I removed the [NFC] tag from the PR title and adjusted the description
accordingly.
https://github.com/llvm/llvm-project/pull/125494
___
cfe-commits maili
@@ -294,6 +294,16 @@ ANALYZER_OPTION(
bool, ShouldUnrollLoops, "unroll-loops",
"Whether the analysis should try to unroll loops with known bounds.",
false)
+ANALYZER_OPTION(
+bool, ShouldAssumeOneIteration, "assume-one-iteration",
+"Whether the analyzer should
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/125494
This commit adds the new analyzer option `assume-one-iteration`, which is
`false` by default, but can be set to `true` to ensure that the analyzer always
assumes (at least) one iteration in loops.
In some si
NagyDonat wrote:
By the way is the "NFC" tag justified for this "add an off-by-default option"
commit? I used this because e.g. if somebody is looking for a bug, they can
safely skip this commit -- but OTOH this _does_ add a new feature.
https://github.com/llvm/llvm-project/pull/125494
___
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/125534
Before this commit, there were two alpha checkers that used different
algorithms/logic for detecting out of bounds memory access: the old
`alpha.security.ArrayBound` and the experimental, more complex
`alpha
NagyDonat wrote:
I evaluated a sample of 10 random ArrayBoundV2 results from FFMPEG and I found
the following:
- [Unjustified assumption of third
iteration](https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?run=ffmpeg_n4.3.1_edonnag_llvm-main_1883de3&newcheck=ffmpeg_n4.3.
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -294,6 +294,16 @@ ANALYZER_OPTION(
bool, ShouldUnrollLoops, "unroll-loops",
"Whether the analysis should try to unroll loops with known bounds.",
false)
+ANALYZER_OPTION(
+bool, ShouldAssumeOneIteration, "assume-one-iteration",
+"Whether the analyzer should
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
701 - 800 of 1140 matches
Mail list logo
