@@ -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 updated
https://github.com/llvm/llvm-project/pull/144327
From bc7dfc2b4f143c2caa1189db096bf9e4ea76f053 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH 1/2] [analyzer] Enforce not making overly compli
balazs-benics-sonarsource wrote:
> The parts of the flamegraph that you highlight are presumably coming from the
> _other_ operand whose simplification is skipped due to the presence of the
> `UnknownVal`.
Yes, this is my theory, but this still wouldn't explain why I didn't see these
simplify
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From bc7dfc2b4f143c2caa1189db096bf9e4ea76f053 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH 1/5] [analyzer] Enforce not making overly compli
balazs-benics-sonarsource wrote:
> > > So, I think if we go with the evalbinop approach, then it should work as
> > > efficiently as my original proposal, while sacreficing the special cases
> > > that fold away the binop. I'm fine with either of the approaches.
> > > I scheduled a measurement
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/144327
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
balazs-benics-sonarsource wrote:
Once we are settled on the implementation here, I'll split the `classof`
refactors from this PR and merge it before merging this one.
Should I measure the perf of this change?
https://github.com/llvm/llvm-project/pull/144327
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From a5ae39c1b8a5abc39f8948a724b354839e708e4b Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH 1/5] [analyzer] Enforce not making overly compli
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed t
balazs-benics-sonarsource wrote:
> [...] This different sort of limitation still guarantees that we cannot build
> overly complex symbols, but its implementation is significantly shorter (just
> three early return statements for unary operator, binary operator and cast
> evaluation).
>
> 💡 In
balazs-benics-sonarsource wrote:
> > So, I think if we go with the evalbinop approach, then it should work as
> > efficiently as my original proposal, while sacreficing the special cases
> > that fold away the binop. I'm fine with either of the approaches.
> > I scheduled a measurement for the
balazs-benics-sonarsource wrote:
> However, I think I see another, less complex approach for "fixing" the method
> `acquire`: instead of creating the `Dummy` symbol and calculating its
> complexity early, just modify the original state of the method (i.e. the
> parent revision of
> [8c29bbc](
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
@@ -46,7 +50,7 @@ class SymbolRegionValue : public SymbolData {
friend class SymExprAllocator;
SymbolRegionValue(SymbolID sym, const TypedValueRegion *r)
- : SymbolData(SymbolRegionValueKind, sym), R(r) {
+ : SymbolData(ClassKind, sym), R(r) {
ba
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed t
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/145501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -134,6 +137,101 @@ class SymbolConjured : public SymbolData {
static constexpr bool classof(Kind K) { return K == ClassKind; }
};
+/// A symbol representing the result of an expression that became too
+/// complicated. In other words, its complexity would have surpassed t
@@ -671,17 +779,33 @@ class SymbolVisitor {
virtual bool VisitMemRegion(const MemRegion *) { return true; }
};
+// Returns a pointer to T if T is a SymbolData, otherwise SymExpr.
balazs-benics-sonarsource wrote:
Reworked the code, and dropped the `auto` typ
balazs-benics-sonarsource wrote:
> > Should I measure the perf of this change?
>
> I think so, because the patch is substantially different. For example, the
> overly complex symbol tree is now preserved, even if it is apparently not
> traversed in its entirety any longer. That makes it not ob
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From a5ae39c1b8a5abc39f8948a724b354839e708e4b Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH 1/3] [analyzer] Enforce not making overly compli
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/145526
This should enable more powerful type metaprograms.
Split from #144327
From 2241ead76477da9eee6b8206a06abe841168b666 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Tue, 24 Jun 2025 16:56:
balazs-benics-sonarsource wrote:
I wanted to look at recently of the history of this test file. I managed to dig
it up, but since the git blame didn't tell me much I think it's worth to spell
out these refs explicitly.
https://github.com/llvm/llvm-project/pull/145501
__
balazs-benics-sonarsource wrote:
Just rebased the PR to exclude the refactor change of `classof`. I'll schedule
a measurement now.
https://github.com/llvm/llvm-project/pull/144327
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
https://github.com/balazs-benics-sonarsource updated
https://github.com/llvm/llvm-project/pull/144327
From 2c32b9f6dfa9a236cea5679b6613e567cd8dfc2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bal=C3=A1zs=20Benics?=
<108414871+balazs-benics-sonarsou...@users.noreply.github.com>
Date: Tue, 24 Jun 20
balazs-benics-sonarsource wrote:
I was thinking about possible ways to unblock this change.
If the additional code complexity needs justification, by measuring the average
impact (to ensure no regression happens in the common cases), and by repeating
the measurement of the handful of edge-case
@@ -45,6 +45,7 @@ SYMBOL(SymbolCast, SymExpr)
ABSTRACT_SYMBOL(SymbolData, SymExpr)
SYMBOL(SymbolConjured, SymbolData)
+ SYMBOL(SymbolTooComplex, SymbolData)
balazs-benics-sonarsource wrote:
Renamed in b9edbc75bc87e4e263cb629f088ae9977a9cac03
https://githu
https://github.com/balazs-benics-sonarsource closed
https://github.com/llvm/llvm-project/pull/145500
___
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/144327
From bc7dfc2b4f143c2caa1189db096bf9e4ea76f053 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 16 Jun 2025 12:14:06 +0200
Subject: [PATCH] [analyzer] Enforce not making overly complicate
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/145501
None
From b67c2c5bfadc80121899690723ba938b398c4e65 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Tue, 24 Jun 2025 13:14:31 +0200
Subject: [PATCH] [analyzer][NFC] Add xrefs to a test case
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/145500
None
From 274a38f83b2c5c81968de865403cf114fc9550c0 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Tue, 24 Jun 2025 13:42:42 +0200
Subject: [PATCH] [analyzer][docs] Mention perfetto for vis
https://github.com/balazs-benics-sonarsource created
https://github.com/llvm/llvm-project/pull/144327
Out of the worst 500 entry points, 45 were improved by at least 10%. Out of
these 45, 5 were improved by more than 50%. Out of these 45, 2 were improved by
more than 80%.
For example, for the
@@ -67,7 +67,7 @@ void ExprEngine::VisitBinaryOperator(const BinaryOperator* B,
if (RightV.isUnknown()) {
unsigned Count = currBldrCtx->blockCount();
RightV = svalBuilder.conjureSymbolVal(nullptr, getCFGElementRef(),
LCtx,
-
@@ -63,6 +64,42 @@ void testGlobalNoThrowPlacementExprNewBeforeOverload() {
int *p = new(std::nothrow) int;
} // leak-warning{{Potential leak of memory pointed to by 'p'}}
+//- Standard pointer placement operators
+void testGlobalPointerPlacementNew() {
+ int i;
+ void
balazs-benics-sonarsource wrote:
> Unfortunately I'm not convinced that this is the right direction for
> improving the analyzer runtime.
>
> On the "risks" side I think that adding the corner case that "this may also
> return `UnknownVal` in rare situations" into many functions complicates th
balazs-benics-sonarsource wrote:
> > I was thinking about possible ways to unblock this change.
> > If the additional code complexity needs justification, by measuring the
> > average impact (to ensure no regression happens in the common cases), and
> > by repeating the measurement of the handf
@@ -317,21 +317,21 @@ class SValBuilder {
return nonloc::LocAsInteger(BasicVals.getPersistentSValWithData(loc,
bits));
}
- nonloc::SymbolVal makeNonLoc(const SymExpr *lhs, BinaryOperator::Opcode op,
- APSIntPtr rhs, QualType type);
+ Defi
balazs-benics-sonarsource wrote:
Backporting this updated version to clang-19 was not easy but it allowed to
verify this PR.
Unfortunately, there is a bug in this updated version, that I'll explain.
Even after I fixed this bug, however, on a sample it ran about 19.36% slower
under analyzing has
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
1 - 100 of 126 matches
Mail list logo
