@@ -926,6 +932,49 @@ void StreamChecker::evalFputx(const FnDescription *Desc,
const CallEvent &Call,
C.addTransition(StateFailed);
}
+void StreamChecker::evalFprintf(const FnDescription *Desc,
+const CallEvent &Call,
+
@@ -916,6 +922,45 @@ void StreamChecker::evalFputx(const FnDescription *Desc,
const CallEvent &Call,
C.addTransition(StateFailed);
}
+void StreamChecker::evalUngetc(const FnDescription *Desc, const CallEvent
&Call,
+ CheckerContext &C) const {
https://github.com/balazs-benics-sonarsource deleted
https://github.com/llvm/llvm-project/pull/77331
___
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/balazs-benics-sonarsource deleted
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/balazs-benics-sonarsource approved this pull request.
I had a look at the PR, and it looks awesome.
Could you please update the attached speedscope image?
It looks like it's out of sync with the implementation, for example if you look
at the "Loc PostStmt { ... stuff here ...}
balazs-benics-sonarsource wrote:
LGTM, I'll merge this PR once the premerge checks are green. Should be ready in
a couple of hours. Thanks for the PR again!
https://github.com/llvm/llvm-project/pull/125508
___
cfe-commits mailing list
cfe-commits@list
balazs-benics-sonarsource wrote:
Looks good as it is right now. Thanks for putting the effort into this.
I've invited the rest of the folks probably interested in this to get a second
opinion.
https://github.com/llvm/llvm-project/pull/131932
___
cfe-c
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/131932
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource approved this pull request.
Thanks for the context. It looks good to me now.
@haoNoQ, maybe you know some Perl, could you have a second opinion?
Otherwise, let's merge this in a week.
https://github.com/llvm/llvm-project/pull/131932
_
balazs-benics-sonarsource wrote:
I'd prefer option 2, because why else would we have a default compiler if that
wasn't used in some workflows.
A warning could never hurt. I'm also flexible on the subject.
https://github.com/llvm/llvm-project/pull/131932
_
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
balazs-benics-sonarsource wrote:
One other note. We should backport this fix to clang-20 once it lands to main.
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
https://github.com/balazs-benics-sonarsource requested changes to this pull
request.
Thank you for investigating this. At Sonar, we have not yet started the upgrade
to clang-20. I suppose, you already did then, thus found this regression on
trunk.
Maybe we should also reflect of the quality c
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
@@ -81,10 +81,6 @@ class FunctionSummariesTy {
I->second.MayInline = 0;
}
- void markReachedMaxBlockCount(const Decl *D) {
-markShouldNotInline(D);
- }
balazs-benics-sonarsource wrote:
I'd not mind keeping this if there was more thing to do once a
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -2856,8 +2873,29 @@ void ExprEngine::processBranch(
// conflicts with the widen-loop analysis option (which is off by
// default). If we intend to support and stabilize the loop widening,
// we must ensure that it 'plays nicely' with this logic.
- if (
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource commented:
Looks good. There were two points unaddressed:
- Finding a name for the flag without the `legacy-` prefix
- Find out if we can ever have multiple root nodes in an exploded graph.
https://github.com/llvm/llvm-project/pull/136720
_
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
balazs-benics-sonarsource wrote:
@Xazax-hun WDYT of the proposed alternative flag name?
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
Do you have data about the analysis times per file, and per analysis entry
point?
Compared against the current llvm main, and also if this workaround would
restore the original running times before
https://github.com/llvm/llvm-project/commit/bb27d5e5c6b194a1440
balazs-benics-sonarsource wrote:
> 🤔 The version with the commit under review is surprisingly fast and I don't
> exactly know why. My most plausible theory is that
> [bb27d5e](https://github.com/llvm/llvm-project/commit/bb27d5e5c6b194a1440b8ac4e5ace68d0ee2a849)
> ("Don't assume third iteration
balazs-benics-sonarsource wrote:
I can see your points. I think they indeed moves the needle slightly for having
this (or a similar) flag but barely.
I'd need to think about a better flag name, but right now I'm too busy for that.
https://github.com/llvm/llvm-project/pull/136720
___
https://github.com/balazs-benics-sonarsource approved this pull request.
Thank you!
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/127602
From f5cd6b22fb83c0bfb584717cde6899cd65fc1274 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Wed, 5 Feb 2025 17:13:34 +0100
Subject: [PATCH 1/7] [analyzer] Limit Store by region-store-bindi
@@ -176,31 +177,59 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefpush_back(V);
+return *this;
+ }
+ RegionBindingsRef escapeValues(nonloc::CompoundVal::iterator Begin,
+ nonloc::CompoundVal::iterator End) const {
+for (SVal V :
@@ -2782,6 +2865,8 @@ RegionBindingsRef
RegionStoreManager::bindStruct(RegionBindingsConstRef B,
if (VI == VE)
break;
+ if (NewB.hasExhaustedBindingLimit())
+return NewB.escapeValues(VI, VE);
balazs-benics-sonarsource wrote:
I've r
@@ -483,6 +483,14 @@ ANALYZER_OPTION(
"behavior, set the option to 0.",
5)
+ANALYZER_OPTION(
+unsigned, RegionStoreMaxBindingFanOut, "region-store-max-binding-fanout",
+"This option limits how many sub-bindings a single binding operation can "
+"scatter int
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
Thanks for your long review. I'm sorry if the poor code quality hindered the
comprehension.
My goal was to minimize the diff for easier review, but I admit that I should
have attached some considerations as to why I implemented it this way, and also
how differe
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/127602
In our test pool, the max entry point RT was improved by this change: 1'181
seconds (~19.7 minutes) -> 94 seconds (1.6 minutes)
BTW, the 1.6 minutes is still really bad. But a few orders of ma
balazs-benics-sonarsource wrote:
@Flandini @necto
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
> Hello @balazs-benics-sonarsource
>
> The following starts crashing with this patch: `clang --analyze bbi-104578.c`
> It crashes with
Thank you for the heads up @mikaelholmen. I'll switch to it ASAP. I'd expect
the fix later today.
https://github.com/llvm/ll
balazs-benics-sonarsource wrote:
Confirmed crash, https://compiler-explorer.com/z/fzoqP36xq
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/129224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -179,8 +181,41 @@ bool CoreEngine::ExecuteWorkList(const LocationContext *L,
unsigned MaxSteps,
return WList->hasWork();
}
-void CoreEngine::dispatchWorkItem(ExplodedNode* Pred, ProgramPoint Loc,
- const WorkListUnit& WU) {
+static std::s
balazs-benics-sonarsource wrote:
> Anyway, let's just merge this as it is now.
>
> The code is basically OK, I still don't have the brainpower to hold all the
> details in my mind (kudos for the fact that _you_ managed to put this
> together) and if I'll catch some divine inspiration in the fu
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -359,7 +326,80 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefhttps://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
balazs-benics-sonarsource wrote:
> As I thought a bit more about the reorganization that I suggested, I realized
> that it can be summarized as **we should synchronize adding the default
> `Unknown` binding and calling `escapeValue`** -- because they correspond to
> the two end-points of the s
@@ -359,7 +326,80 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefhttps://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/131932
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/133236
These metrics would turn out to be useful for verifying an upgrade of Z3.
From 5fe04bcbb3eaf5682037ada6ab64fd7e021f787e Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 27 Mar 2025 12:1
balazs-benics-sonarsource wrote:
Thanks for the fix, I'll proceed with the backport if you still believe it's
worthy. @NagyDonat
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/140035
This change helps with ensuring that the abstract machine call stack is only
dumped exactly once no matter what checker callback we have the crash in.
Note that some checker callbacks happen o
balazs-benics-sonarsource wrote:
/CC @pdschbrt
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140035
From 42343959f623153dc9421e3bb569b2f0527ec119 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 11:17:24 +0200
Subject: [PATCH 1/2] [analyzer][NFC] Move PrettyStackTraceLocati
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140924
From 084d821b62d5de473d32d3506da95fdd7bad1cfe Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 17:20:29 +0200
Subject: [PATCH 1/3] [analyzer] Introduce the check::BlockEntran
balazs-benics-sonarsource wrote:
> What is the relationship of this new callback with the `BranchCondition`
> callback which is evaluated in `ProcessBranch` where the checker splits the
> execution path into multiple branches? It would be nice if you could document
> the difference between the
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/140861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/140924
Tranersing the CFG blocks of a function is a fundamental operation. Many C++
constructs can create splits in the control-flow, such as `if`, `for`, and
similar control structures or ternary ex
balazs-benics-sonarsource wrote:
I've updated the PR. I noticed some mistakes in the original submission.
Could you please have a look?
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140035
From 3ef0391fdc58503f3414ac64e42370b0a6d4bddf Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 11:17:24 +0200
Subject: [PATCH] [analyzer][NFC] Move PrettyStackTraceLocationCo
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource edited
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/140035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
/cc @necto
https://github.com/llvm/llvm-project/pull/140861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/140861
This helps to gain contextual information about how we entered a CFG block.
The `noexprcrash.c` test probably changed due to the fact that now
BlockEntrance ProgramPoint Profile also hashes th
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140924
From 084d821b62d5de473d32d3506da95fdd7bad1cfe Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 17:20:29 +0200
Subject: [PATCH 1/4] [analyzer] Introduce the check::BlockEntran
@@ -548,6 +564,8 @@ class CheckerProgramPointTag : public SimpleProgramPointTag
{
template
class Checker : public CHECK1, public CHECKs..., public CheckerBase {
public:
+ using BlockEntrance = clang::BlockEntrance;
balazs-benics-sonarsource wrote:
Yes, the
@@ -548,6 +564,8 @@ class CheckerProgramPointTag : public SimpleProgramPointTag
{
template
class Checker : public CHECK1, public CHECKs..., public CheckerBase {
public:
+ using BlockEntrance = clang::BlockEntrance;
balazs-benics-sonarsource wrote:
> Note th
balazs-benics-sonarsource wrote:
I know it didn't actually pass a week for a ping, but let me know if its on the
horizon.
https://github.com/llvm/llvm-project/pull/140924
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -166,6 +179,23 @@ class CheckerDocumentation
/// check::Bind
void checkBind(SVal Loc, SVal Val, const Stmt *S, CheckerContext &) const {}
+ /// Called after a CFG edge is taken within a function.
+ ///
+ /// This callback can be used to obtain information about poten
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/140924
From 084d821b62d5de473d32d3506da95fdd7bad1cfe Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 15 May 2025 17:20:29 +0200
Subject: [PATCH 1/7] [analyzer] Introduce the check::BlockEntran
@@ -166,6 +179,23 @@ class CheckerDocumentation
/// check::Bind
void checkBind(SVal Loc, SVal Val, const Stmt *S, CheckerContext &) const {}
+ /// Called after a CFG edge is taken within a function.
+ ///
+ /// This callback can be used to obtain information about poten
balazs-benics-sonarsource wrote:
> In the tests I felt that it'd be a bit hard to decipher the meaning of the
> block identifiers like `B1` etc. -- but when I re-read the file I noticed
> that you included the very nice helper function `dumpCFGAndEgraph` (IIUC) for
> those who will need to deb
balazs-benics-sonarsource wrote:
> @steakhal Thanks for the updates, I'm completely satisfied with them.
>
> I don't see any connection between this commit and the buildbot failures 🤔
> ... they are probably unrelated.
About 90% of the time they are unrelated. I don't usually put a confirmatio
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/140924
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
78 matches
Mail list logo
