https://github.com/necto edited https://github.com/llvm/llvm-project/pull/106048
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/106048
>From 7d5ae515f7727de98e7e8ce2f259e579a1f24463 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Tue, 20 Aug 2024 17:31:11 +0200
Subject: [PATCH 1/6] [analyzer] Report violations of the "returns_nonnull"
necto wrote:
> Please update the documentation of the affected checkers (in
> clang/docs/analyzer/checkers.rst) to mark that they are no longer limited to
> Objective-C.
Updated in 2d2ab3185a00
https://github.com/llvm/llvm-project/pull/106048
___
cf
https://github.com/necto approved this pull request.
https://github.com/llvm/llvm-project/pull/112583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -50,31 +50,10 @@ void test2() {
b = d;
a -= d;
- if (a != 0)
-return;
-
- clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+ clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
- /* The BASELINE passes these checks ('wrning' is us
@@ -1939,11 +1956,8 @@ class RangeConstraintManager : public
RangedConstraintManager {
RangeSet::Factory F;
RangeSet getRange(ProgramStateRef State, SymbolRef Sym);
- RangeSet getRange(ProgramStateRef State, EquivalenceClass Class);
ProgramStateRef setRange(ProgramSta
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/113908
Model:
- `wcscpy`
- `wcsncpy`
- `wcscat`
- `wcsncat`
- `swprintf`
- `wmemset`
- `wcscmp` (partially)
- `wcsncmp` (partially)
All models draw from their regular-char counterparts.
Additionally, `sprintf`, `snprint
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/109655
Fixes #107852
Make it explicit that the checker skips alloca regions to avoid the risc of
producing false positives for code that has advnaced memory management.
StackAddrEscapeChecker already used this strategy
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/109655
>From b69749ab1854b0c12a69821c35bff1b866d6f307 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 23 Sep 2024 14:21:31 +0200
Subject: [PATCH 1/3] [analyzer][StackAddrEscapeChecker] Fix assert failure f
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/109655
>From b69749ab1854b0c12a69821c35bff1b866d6f307 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 23 Sep 2024 14:21:31 +0200
Subject: [PATCH 1/2] [analyzer][StackAddrEscapeChecker] Fix assert failure f
@@ -846,3 +851,25 @@ void top(char **p) {
foo(); // no-warning FIXME: p binding is reclaimed before the function end
}
} // namespace early_reclaim_dead_limitation
+
+using size_t = decltype(sizeof(int));
+void * malloc(size_t size);
+void free(void*);
necto
@@ -1,4 +1,9 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify
%s -Wno-undefined-bool-conversion
+// RUN: %clang_analyze_cc1 \
+// RUN: -analyzer-checker=core,debug.ExprInspection,unix.Malloc \
+// RUN: -verify %s \
+// RUN: -Wno-undefined-b
@@ -2092,6 +2092,10 @@ void Sema::CheckCompatibleReinterpretCast(QualType
SrcType, QualType DestType,
}
}
+ if (SrcTy->isTemplateTypeParmType() || DestTy->isTemplateTypeParmType()) {
necto wrote:
Good point
Fixed in 541e0af03998
https://github.com/ll
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/109430
>From 3533863fd58f54d2d5570b4f593d2635e1e11aa8 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Fri, 20 Sep 2024 09:16:17 +0200
Subject: [PATCH 1/2] [clang] Fix false warning on reinterpret_casting unknow
necto wrote:
> Please mark the line in the test with `no-crash` where previously crashed.
Done in b2ed9f9
> Speaking of the fix, I think anything is better than a crash, but I wonder if
> we could do more. To me, once an alloca region goes out of scope, that should
> behave just as if a regul
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/109655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/109655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/109655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/109655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/109430
After 1595988ee6f9732e7ea79928af8a470ad5ef7dbe
diag::warn_undefined_reinterpret_cast started raising on non-instantiated
template functions without sufficient knowledge whether the reinterpret_cast is
indeed UB.
https://github.com/necto approved this pull request.
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/necto created
https://github.com/llvm/llvm-project/pull/117863
The motivating example:
```C++
void inf_loop_break_callee() {
void* data = malloc(10);
while (1) {
(void)data; // line 4
break; // -> execution continues on line 4 ?!!
}
}
void inf_loop_break_caller(
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/117863
>From c725ed73555a3b9080541fe7d4a71ceef0b04762 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 25 Nov 2024 16:06:53 +0100
Subject: [PATCH 1/2] [analyzer] Avoid out-of-order node traversal on void
r
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/117863
>From c725ed73555a3b9080541fe7d4a71ceef0b04762 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 25 Nov 2024 16:06:53 +0100
Subject: [PATCH 1/4] [analyzer] Avoid out-of-order node traversal on void
r
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/117863
>From c725ed73555a3b9080541fe7d4a71ceef0b04762 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 25 Nov 2024 16:06:53 +0100
Subject: [PATCH 1/5] [analyzer] Avoid out-of-order node traversal on void
r
@@ -278,7 +278,9 @@ class ExplodedNode : public llvm::FoldingSetNode {
/// Useful for explaining control flow that follows the current node.
/// If the statement belongs to a body-farmed definition, retrieve the
/// call site for that definition.
- const Stmt *getNextStm
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/117863
>From c725ed73555a3b9080541fe7d4a71ceef0b04762 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 25 Nov 2024 16:06:53 +0100
Subject: [PATCH 1/3] [analyzer] Avoid out-of-order node traversal on void
r
@@ -347,8 +347,11 @@ const Stmt *ExplodedNode::getStmtForDiagnostics() const {
return nullptr;
}
-const Stmt *ExplodedNode::getNextStmtForDiagnostics() const {
+const Stmt *ExplodedNode::getNextStmtForDiagnostics(bool skipPurge) const {
for (const ExplodedNode *N = getFir
@@ -278,7 +278,9 @@ class ExplodedNode : public llvm::FoldingSetNode {
/// Useful for explaining control flow that follows the current node.
/// If the statement belongs to a body-farmed definition, retrieve the
/// call site for that definition.
- const Stmt *getNextStm
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+//
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+//
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+//
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/121551
>From 115814c2776b6acc8f4a08ec696a3cb27a7c0ebd Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Thu, 2 Jan 2025 09:58:53 +0100
Subject: [PATCH 1/5] Add SymbolID to every SymExpr, not just SymbolData
---
necto wrote:
> By the way, what fraction of the results is perturbed (replaced with other
> random results) when this commit is activated? Did you run any "without this
> commit vs with this commit" comparisons?
The difference is around 5-10 appearing/disappearing issues, and 50-100 issues
wi
@@ -56,6 +68,8 @@ class SymExpr : public llvm::FoldingSetNode {
Kind getKind() const { return K; }
+ SymbolID getSymbolID() const { return Sym; }
necto wrote:
Documented in
355c588f4469 az/order-by-symref-id [NFC] A doc comment explaining the
SymExpr::ge
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/121551
>From 115814c2776b6acc8f4a08ec696a3cb27a7c0ebd Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Thu, 2 Jan 2025 09:58:53 +0100
Subject: [PATCH 1/4] Add SymbolID to every SymExpr, not just SymbolData
---
@@ -427,8 +434,8 @@ class BinarySymExprImpl : public BinarySymExpr {
public:
BinarySymExprImpl(LHSTYPE lhs, BinaryOperator::Opcode op, RHSTYPE rhs,
-QualType t)
- : BinarySymExpr(ClassKind, op, t), LHS(lhs), RHS(rhs) {
+QualType t
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/121781
Replace the family of `SymbolManager::get*Symbol(...)` member functions with a
single generic `SymbolManager::get<*>` member function.
>From 08b838adf275f1e0eaf2ab3e3d4b2b6d89bf4ed6 Mon Sep 17 00:00:00 2001
From:
necto wrote:
@NagyDonat Here is the refactoring you suggested in
https://github.com/llvm/llvm-project/pull/121551
I made sure `check-clang-analysis` passes after each commit, so I think
reviewing it by commit should be easier than all at once.
https://github.com/llvm/llvm-project/pull/121781
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/121781
>From 08b838adf275f1e0eaf2ab3e3d4b2b6d89bf4ed6 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 6 Jan 2025 14:37:08 +0100
Subject: [PATCH 01/11] [NFC] Replace getRegionValueSymbol with
get
This sho
https://github.com/necto updated
https://github.com/llvm/llvm-project/pull/121781
>From 08b838adf275f1e0eaf2ab3e3d4b2b6d89bf4ed6 Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Mon, 6 Jan 2025 14:37:08 +0100
Subject: [PATCH 01/12] [NFC] Replace getRegionValueSymbol with
get
This sho
@@ -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);
---
@@ -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/necto created
https://github.com/llvm/llvm-project/pull/121749
Generalize the SymbolIDs used for SymbolData to all SymExprs and use these IDs
for comparison SymbolRef keys in various containers, such as ConstraintMap.
These IDs are superior to raw pointer values because they
necto wrote:
@steakhal I've fixed the buildbot error ensued after
https://github.com/llvm/llvm-project/pull/121551 was merged
https://github.com/llvm/llvm-project/pull/121749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
necto wrote:
Hey, @steakhal, @NagyDonat
I am working caching Z3 refutation query outcomes to reduce the number of flaky
issues, and constraint order is important to maximize the cache-hit rate. Turns
out, global constraint order is beneficial regardless query cache. Would you
take a look?
BT
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/121347
These IDs are essentially allocator offsets for the SymExpr pool. They are
superior to raw pointer values because they are more controllable and are not
randomized across executions.
They are not stable across r
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/121347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/121347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -179,8 +181,40 @@ bool CoreEngine::ExecuteWorkList(const LocationContext *L,
unsigned MaxSteps,
return WList->hasWork();
}
-void CoreEngine::dispatchWorkItem(ExplodedNode* Pred, ProgramPoint Loc,
- const WorkListUnit& WU) {
+static std::s
@@ -365,13 +388,22 @@ namespace {
void runChecker(CheckerManager::CheckBindFunc checkFn,
NodeBuilder &Bldr, ExplodedNode *Pred) {
+ llvm::TimeTraceScope TimeScope(checkerScopeName("Bind",
checkFn.Checker));
const ProgramPoint &L = PP.withTa
@@ -287,6 +288,34 @@ class PathDiagnosticBuilder : public BugReporterContext {
const PathSensitiveBugReport *getBugReport() const { return R; }
};
+std::string timeTraceName(const BugReportEquivClass &EQ) {
+ if (!llvm::timeTraceProfilerEnabled())
+return "";
+ const a
@@ -287,6 +288,34 @@ class PathDiagnosticBuilder : public BugReporterContext {
const PathSensitiveBugReport *getBugReport() const { return R; }
};
+std::string timeTraceName(const BugReportEquivClass &EQ) {
+ if (!llvm::timeTraceProfilerEnabled())
+return "";
+ const a
@@ -358,9 +359,41 @@ class AnalysisConsumer : public AnalysisASTConsumer,
/// Print \p S to stderr if \c Opts.AnalyzerDisplayProgress is set.
void reportAnalyzerProgress(StringRef S);
-}; // namespace
-} // end anonymous namespace
+};
+std::string timeTraceScopeDeclName(
@@ -119,6 +121,28 @@ class CacheInitializer : public DynamicRecursiveASTVisitor
{
Ranges &Result;
};
+std::string timeScopeName(const Decl *DeclWithIssue) {
+ if (!llvm::timeTraceProfilerEnabled())
+return "";
+ return llvm::formatv(
+ "BugSuppression::isS
@@ -287,6 +288,34 @@ class PathDiagnosticBuilder : public BugReporterContext {
const PathSensitiveBugReport *getBugReport() const { return R; }
};
+std::string timeTraceName(const BugReportEquivClass &EQ) {
+ if (!llvm::timeTraceProfilerEnabled())
+return "";
+ const a
@@ -119,6 +121,28 @@ class CacheInitializer : public DynamicRecursiveASTVisitor
{
Ranges &Result;
};
+std::string timeScopeName(const Decl *DeclWithIssue) {
+ if (!llvm::timeTraceProfilerEnabled())
+return "";
+ return llvm::formatv(
+ "BugSuppression::isS
@@ -134,6 +135,14 @@ static void expandGraphWithCheckers(CHECK_CTX checkCtx,
namespace {
+std::string checkerScopeName(StringRef name, const CheckerBase *checker) {
+ if (!llvm::timeTraceProfilerEnabled())
+return "";
+ std::string checkerName =
necto w
@@ -358,9 +359,41 @@ class AnalysisConsumer : public AnalysisASTConsumer,
/// Print \p S to stderr if \c Opts.AnalyzerDisplayProgress is set.
void reportAnalyzerProgress(StringRef S);
-}; // namespace
-} // end anonymous namespace
+};
+std::string timeTraceScopeDeclName(
necto wrote:
> Does this also work when CSA is called through clang-tidy? The analyzer
> profiling data in missing in the `--enable-check-profile` output - see #73673?
As far as I know, it does not work out of the box with clang-tidy. Time tracing
works only if you setup a profiler singleton i
@@ -49,6 +49,127 @@ LLVM_DUMP_METHOD void ProgramPoint::dump() const {
return printJson(llvm::errs());
}
+const char *ProgramPoint::kindToStr(Kind K) {
+ switch (K) {
+ case BlockEdgeKind:
+return "BlockEdge";
+ case BlockEntranceKind:
+return "BlockEntrance";
+
@@ -0,0 +1,38 @@
+=
+Performance Investigation
+=
+
+Multiple factors contribute to the time it takes to analyze a file with Clang
Static Analyzer.
+A translation unit contains multiple entry points, each of which take multiple
ste
@@ -0,0 +1,38 @@
+=
+Performance Investigation
+=
+
+Multiple factors contribute to the time it takes to analyze a file with Clang
Static Analyzer.
+A translation unit contains multiple entry points, each of which take multiple
ste
@@ -49,6 +49,127 @@ LLVM_DUMP_METHOD void ProgramPoint::dump() const {
return printJson(llvm::errs());
}
+const char *ProgramPoint::kindToStr(Kind K) {
necto wrote:
Indeed, I changed the return type in
a22ed13eae22 [NFC] Return StringRef instead of a raw ch
@@ -49,6 +49,127 @@ LLVM_DUMP_METHOD void ProgramPoint::dump() const {
return printJson(llvm::errs());
}
+const char *ProgramPoint::kindToStr(Kind K) {
+ switch (K) {
+ case BlockEdgeKind:
+return "BlockEdge";
+ case BlockEntranceKind:
+return "BlockEntrance";
+
@@ -287,6 +288,35 @@ class PathDiagnosticBuilder : public BugReporterContext {
const PathSensitiveBugReport *getBugReport() const { return R; }
};
+std::string timeTraceName(const BugReportEquivClass &EQ) {
+ if (!llvm::timeTraceProfilerEnabled()) {
necto w
necto wrote:
> 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
> ...}" , it appears to include the ProgramPoint dump, a
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/125884
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/125884
>From investigation of a few slow analysis cases, I discovered that
>`RegionStoreManager::bind*` and `ExprEngine::removeDead` are often the slowest
>actions. This change adds explicit scope to the time trace gene
@@ -1031,6 +1032,7 @@ void ExprEngine::removeDead(ExplodedNode *Pred,
ExplodedNodeSet &Out,
const LocationContext *LC,
const Stmt *DiagnosticStmt,
ProgramPoint::Kind K) {
+ llvm::TimeTraceScop
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/125884
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1031,6 +1032,7 @@ void ExprEngine::removeDead(ExplodedNode *Pred,
ExplodedNodeSet &Out,
const LocationContext *LC,
const Stmt *DiagnosticStmt,
ProgramPoint::Kind K) {
+ llvm::TimeTraceScop
@@ -45,3 +48,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
@@ -45,3 +48,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
@@ -45,3 +48,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
https://github.com/necto commented:
One note about the illustrations:
Thank you for adding them, I think they are invaluable to understand the docs!
Yet, I feel they could be smaller both in detail and in the file sizes.
- Fewer details means the reader will quicker understand the points you want
@@ -45,3 +48,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
@@ -45,3 +48,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
@@ -45,3 +47,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
@@ -45,3 +47,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
https://github.com/necto approved this pull request.
https://github.com/llvm/llvm-project/pull/126724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,64 @@
+//== APSIntPtr.h - Wrapper for APSInt objects owned separately -*- C++ -*--==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -165,79 +166,70 @@ class BasicValueFactory {
/// Convert - Create a new persistent APSInt with the same value as 'From'
/// but with the bitwidth and signedness of 'To'.
- const llvm::APSInt &Convert(const llvm::APSInt& To,
- const llvm::A
https://github.com/necto requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/120435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto approved this pull request.
https://github.com/llvm/llvm-project/pull/120435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
necto wrote:
@cor3ntin is it good to go now?
https://github.com/llvm/llvm-project/pull/109430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto approved this pull request.
I don't know the best practices related to release notes, but the changes look
good to me
https://github.com/llvm/llvm-project/pull/124798
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
necto wrote:
> LGTM. Do you need me to merge that for you?
Yes, please
https://github.com/llvm/llvm-project/pull/109430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -427,8 +434,8 @@ class BinarySymExprImpl : public BinarySymExpr {
public:
BinarySymExprImpl(LHSTYPE lhs, BinaryOperator::Opcode op, RHSTYPE rhs,
-QualType t)
- : BinarySymExpr(ClassKind, op, t), LHS(lhs), RHS(rhs) {
+QualType t
@@ -401,7 +401,22 @@ class RangeSet {
friend class Factory;
};
-using ConstraintMap = llvm::ImmutableMap;
+struct ConstraintKVInfo : llvm::ImutKeyValueInfo {
+ static inline bool isEqual(key_type_ref L, key_type_ref R) {
+return L->getAllocID() == R->getAllocID();
+ }
https://github.com/necto created
https://github.com/llvm/llvm-project/pull/121551
Generalize the `SymbolID`s used for `SymbolData` to all `SymExpr`s and use
these IDs for comparison `SymbolRef` keys in various containers, such as
`ConstraintMap`. These IDs are superior to raw pointer values be
necto wrote:
@steakhal @NagyDonat, I revised and improved #121347.
To facilitate review, I broke the change down into 3 self-contained commits.
let tests pass after each of them.
I re-evaluated this version and discovered no difference in the analysis
outcome.
https://github.com/llvm/llvm-proj
https://github.com/necto closed https://github.com/llvm/llvm-project/pull/121347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
necto wrote:
Superseded by https://github.com/llvm/llvm-project/pull/121551
https://github.com/llvm/llvm-project/pull/121347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/necto edited https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
necto wrote:
> That being said, do we know how exactly the unstable addresses result in
> unstable results?
One mechanism that we studied in the past weeks is the SMT issue refutation:
assertion order is that of the constraint order in the `ConstraintMap`, and it
turns out Z3 runs a query dif
@@ -401,7 +401,22 @@ class RangeSet {
friend class Factory;
};
-using ConstraintMap = llvm::ImmutableMap;
+struct ConstraintKVInfo : llvm::ImutKeyValueInfo {
+ static inline bool isEqual(key_type_ref L, key_type_ref R) {
+return L->getAllocID() == R->getAllocID();
+ }
necto wrote:
> Does the unstable constraint order only affect Z3 refutation, or did you
> measure/notice differences in report flakyness even without Z3 refutation? I
> think it would be great to see the impact of this change, while we eliminate
> the Z3 from the equation.
I've measured it n
101 - 200 of 230 matches
Mail list logo
