https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/115884
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
This is now superseded by the individual commits (PRs).
https://github.com/llvm/llvm-project/pull/114835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/115917
Split from #114835
>From a16c5e514b5a80b20e7a7eb377686012026d2dc4 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 2 Nov 2024 14:13:00 +0100
Subject: [PATCH 1/2] [analyzer] Allow copying empty structs (
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/115917
>From a16c5e514b5a80b20e7a7eb377686012026d2dc4 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 2 Nov 2024 14:13:00 +0100
Subject: [PATCH 1/2] [analyzer] Allow copying empty structs (1/4)
We represent c
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/85224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
There are fundamental problems with using stdout and FileCheck. Those
assertions (`CHECK` line) depend on their relative ordering. However, the
ordering of the top-level entry points may c
https://github.com/steakhal commented:
Oh yes, I already reviewed this one.
I had only a few comments, otherwise it's good to me.
I'll get upstream folks involved on this one.
https://github.com/llvm/llvm-project/pull/113908
___
cfe-commits mailing lis
@@ -2524,8 +2625,33 @@ void CStringChecker::evalStdCopyCommon(CheckerContext &C,
C.addTransition(State);
}
-void CStringChecker::evalMemset(CheckerContext &C,
-const CallEvent &Call) const {
+namespace {
+CharUnits getSizeOfUnit(CharKind CK, C
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/113908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2524,8 +2625,33 @@ void CStringChecker::evalStdCopyCommon(CheckerContext &C,
C.addTransition(State);
}
-void CStringChecker::evalMemset(CheckerContext &C,
-const CallEvent &Call) const {
+namespace {
+CharUnits getSizeOfUnit(CharKind CK, C
@@ -2524,8 +2625,33 @@ void CStringChecker::evalStdCopyCommon(CheckerContext &C,
C.addTransition(State);
}
-void CStringChecker::evalMemset(CheckerContext &C,
-const CallEvent &Call) const {
+namespace {
+CharUnits getSizeOfUnit(CharKind CK, C
steakhal wrote:
One more note: Anyone reviewing this, don't be afraid of the size of the PR.
Basically 3/4 is just tests.
https://github.com/llvm/llvm-project/pull/113908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
steakhal wrote:
@Endilll Could you please help me reaching out to the right set of reviewers?
https://github.com/llvm/llvm-project/pull/109574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/115881
Reverts llvm/llvm-project#115615
There are two problems with this PR:
1) If any of the dumps contains a store with a symbolic binding, we crash.
2) The memory space clusters come last among the clusters, whic
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/115881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
We crash because even calling the `getRegion()` raises an assert that the
binding should be a symbolic binding.
https://github.com/llvm/llvm-project/pull/115881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/115884
>From 7c20b117b8cad0fa5b999c86f507d9356e8b41de Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 9 Nov 2024 15:55:08 +0100
Subject: [PATCH 1/3] [analyzer][NFC] Make RegionStore dumps deterministic
Dump t
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/114835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/115615
>From 26f0cfabe3328c8eb8a861dd5d1d541921499f0c Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 9 Nov 2024 15:55:08 +0100
Subject: [PATCH 1/3] [analyzer][NFC] Make RegionStore dumps deterministic
Dump t
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/115615
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/109574
This helps to produce USRs for custom LangOpts - that differ from the one
associated with the given Decl. This can unlock usecases in tooling
opportunities that we have downstream.
This is NFC because existin
https://github.com/steakhal approved this pull request.
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/steakhal closed
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/steakhal 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/steakhal commented:
Please mark the line in the test with `no-crash` where previously crashed.
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
regu
@@ -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
@@ -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*);
steakh
steakhal wrote:
For example the following code would get different USRs in C and C++:
```c++
static int f1(int* x);
// USR in C: c:input.cc@F@f1
// USR in C++: c:input.cc@F@f1#*I#
```
So by having this patch, it would be possible to generate the C++ USR even if
the AST (thus the ASTContext) w
https://github.com/steakhal approved this pull request.
LGTM. Maybe in the future we could think of passing a ProgramPoint or something
similar to avoid manually forwarding the location context, the statement, the
counter, and all that.
https://github.com/llvm/llvm-project/pull/109792
steakhal wrote:
> Hm, that looks very unrelated.
>
> > Memory access fault by GPU node-1 (Agent handle: 0x5613bf3d5ac0) on address
> > (nil). Reason: Page not present or supervisor privilege.
No worries
https://github.com/llvm/llvm-project/pull/109792
https://github.com/steakhal commented:
Looks correct to me.
Btw, do you think the invalidation should cause pointer escape? I have no
opinion. I rarely use this api. Wdyt?
https://github.com/llvm/llvm-project/pull/109838
___
cfe-commits mailing list
c
@@ -40,7 +42,19 @@ void testInlineAsmMemcpyUninit(void)
{
int a[10], b[10] = {}, c;
MyMemcpy(&a[1], &b[1], sizeof(b) - sizeof(b[1]));
-c = a[0]; // expected-warning{{Assigned value is garbage or undefined}}
+c = a[0]; // FIXME: should be warning about uninitiali
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/109792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Bal=C3=A1zs_K=C3=A9ri?=
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
Still makes sense.
https://github.com/llvm/llvm-project/pull/107596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/109112
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/109104
Patch by Alejandro Alvarez Ayllon!
CPP-5380
>From f495ed375b0581d475e13636e201cef57718d127 Mon Sep 17 00:00:00 2001
From: Alejandro _lvarez Ayll_n
Date: Wed, 18 Sep 2024 10:58:03 +0200
Subject: [PATCH] [clang
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/109112
>From 408ee82b1ee3ae15302b2a0dde9faded3e43bf0f Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Wed, 18 Sep 2024 11:30:10 +0200
Subject: [PATCH 1/2] [analyzer] Note last "fclose" call from
"ensureStre
steakhal wrote:
I'm okay with the PR, but this leaves me wonder how did you end up with this
crash?
How did you manage to avoid all the zillion other ways to crash the Z3 solver?
Have you experienced such issues?
https://github.com/llvm/llvm-project/pull/108900
steakhal wrote:
> > I'm okay with the PR, but this leaves me wonder how did you end up with
> > this crash? How did you manage to avoid all the zillion other ways to crash
> > the Z3 solver? Have you experienced such issues?
>
> Thanks Balazs, TBH I'm not sure we've found all the ways to crash
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/109098
None
>From cbbfe3853d19b095e63b1ff1a016d4bd8aed0dfc Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Wed, 18 Sep 2024 10:33:34 +0200
Subject: [PATCH] [clang][NFC] Remove trailing spaces from Sema diag messag
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/109112
Patch by Arseniy Zaostrovnykh!
>From 408ee82b1ee3ae15302b2a0dde9faded3e43bf0f Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Wed, 18 Sep 2024 11:30:10 +0200
Subject: [PATCH] [analyzer] Note last "fc
https://github.com/steakhal commented:
I wish we had something like this. It might be possible, but really really
challenging to implement.
To me the problem is that the iteration or lookups are not necessarily bad. And
to determine if it's bad one needs to understand how the result of the look
@@ -50,6 +122,107 @@ class BuiltinFunctionChecker : public Checker {
} // namespace
+const NoteTag *BuiltinFunctionChecker::createBuiltinNoOverflowNoteTag(
+CheckerContext &C, bool bothFeasible, SVal Arg1, SVal Arg2,
+SVal Result) const {
+ return C.getNoteTag([Resul
@@ -50,6 +101,44 @@ class BuiltinFunctionChecker : public Checker {
} // namespace
+void BuiltinFunctionChecker::HandleOverflowBuiltin(const CallEvent &Call,
+ CheckerContext &C,
+
@@ -50,6 +122,107 @@ class BuiltinFunctionChecker : public Checker {
} // namespace
+const NoteTag *BuiltinFunctionChecker::createBuiltinNoOverflowNoteTag(
+CheckerContext &C, bool bothFeasible, SVal Arg1, SVal Arg2,
+SVal Result) const {
+ return C.getNoteTag([Resul
@@ -50,6 +122,107 @@ class BuiltinFunctionChecker : public Checker {
} // namespace
+const NoteTag *BuiltinFunctionChecker::createBuiltinNoOverflowNoteTag(
+CheckerContext &C, bool bothFeasible, SVal Arg1, SVal Arg2,
steakhal wrote:
```suggestion
Che
@@ -0,0 +1,157 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-unknown-unknown -verify %s \
+// RUN: -analyzer-checker=core,debug.ExprInspection
+
+#define __UINT_MAX__ (__INT_MAX__ * 2U + 1U)
+#define __INT_MIN__ (-__INT_MAX__ - 1)
+
+void clang_analyzer_dump_int(int);
+void cla
@@ -50,6 +122,107 @@ class BuiltinFunctionChecker : public Checker {
} // namespace
+const NoteTag *BuiltinFunctionChecker::createBuiltinNoOverflowNoteTag(
+CheckerContext &C, bool bothFeasible, SVal Arg1, SVal Arg2,
+SVal Result) const {
+ return C.getNoteTag([Resul
https://github.com/steakhal approved this pull request.
https://github.com/llvm/llvm-project/pull/106389
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,157 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-unknown-unknown -verify %s \
+// RUN: -analyzer-checker=core,debug.ExprInspection
+
+#define __UINT_MAX__ (__INT_MAX__ * 2U + 1U)
+#define __INT_MIN__ (-__INT_MAX__ - 1)
+
+void clang_analyzer_dump_int(int);
+void cla
https://github.com/steakhal approved this pull request.
Looks fantastic! I have no functional remarks. I only sprinkled it with some
nits, but other than those it's perfect.
It's already good, I'll let you decide if you want to do the final touches or
not as those may be more subjective suggest
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/102602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -327,6 +327,8 @@ Static Analyzer
New features
+- Now CSA models `__builtin_*_overflow` functions.
steakhal wrote:
```suggestion
- Now CSA models `__builtin_*_overflow` functions. (#GH102602)
```
https://github.com/llvm/llvm-project/pull/10260
@@ -16,21 +16,93 @@
#include "clang/Basic/Builtins.h"
#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
+#include "clang/StaticAnalyzer/Checkers/Taint.h"
#include "clang/StaticAnalyzer/Core/Checker.h"
#include "clang/StaticAnalyzer/Core/CheckerManager.h"
@@ -0,0 +1,30 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output text \
+// RUN: -verify %s
+
+void test_no_overflow_note(int a, int b)
+{
+ int res;
+
+ if (__builtin_add_overflow(a, b, &res)) // expected-note {{Assuming
overflow does not happen}}
-
@@ -10,8 +10,10 @@ void testRValueOutput() {
int &ref = global;
ref = 1;
__asm__("" : "=r"(((int)(global; // don't crash on rvalue output operand
- clang_analyzer_eval(global == 1); // expected-warning{{UNKNOWN}}
- clang_analyzer_eval(ref == 1);// expected-warn
https://github.com/steakhal approved this pull request.
A direct bind can be always swapped out for an invalidation, so this PR is
correct.
I wonder if you have plans for interpreting the asm block to see if we could do
something better - e.g. because we could infer that it will only write a
s
@@ -40,7 +42,19 @@ void testInlineAsmMemcpyUninit(void)
{
int a[10], b[10] = {}, c;
MyMemcpy(&a[1], &b[1], sizeof(b) - sizeof(b[1]));
-c = a[0]; // expected-warning{{Assigned value is garbage or undefined}}
+c = a[0]; // FIXME: should be warning about uninitiali
@@ -49,6 +63,6 @@ void testAsmWithVoidPtrArgument()
clang_analyzer_dump(*(int *)globalVoidPtr); // expected-warning-re
{{reg_${{[0-9]+}}},0 S64b,int}>}}
clang_analyzer_dump_ptr(globalVoidPtr); // expected-warning-re
{{&SymRegion{reg_${{[0-9]+}
asm ("" : : "a"(global
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/109838
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -40,7 +42,19 @@ void testInlineAsmMemcpyUninit(void)
{
int a[10], b[10] = {}, c;
MyMemcpy(&a[1], &b[1], sizeof(b) - sizeof(b[1]));
-c = a[0]; // expected-warning{{Assigned value is garbage or undefined}}
+c = a[0]; // FIXME: should be warning about uninitiali
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/109098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
Thanks for the prompt review!
https://github.com/llvm/llvm-project/pull/109098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/109104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/109112
>From 408ee82b1ee3ae15302b2a0dde9faded3e43bf0f Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Wed, 18 Sep 2024 11:30:10 +0200
Subject: [PATCH 1/3] [analyzer] Note last "fclose" call from
"ensureStre
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/109112
>From 408ee82b1ee3ae15302b2a0dde9faded3e43bf0f Mon Sep 17 00:00:00 2001
From: Arseniy Zaostrovnykh
Date: Wed, 18 Sep 2024 11:30:10 +0200
Subject: [PATCH 1/4] [analyzer] Note last "fclose" call from
"ensureStre
https://github.com/steakhal requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/110977
___
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->
@@ -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/steakhal edited
https://github.com/llvm/llvm-project/pull/110977
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -23,38 +25,35 @@ using namespace ento;
namespace {
class FixedAddressChecker
- : public Checker< check::PreStmt > {
+: public Checker, check::PreStmt,
+ check::PreStmt> {
const BugType BT{this, "Use fixed address"};
+ void checkUseOfFixedAddre
@@ -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->
@@ -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/steakhal closed
https://github.com/llvm/llvm-project/pull/102602
___
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->
steakhal wrote:
> > However, what should we do if multiple (N) classes implement Base? Trying
> > each N, and basically splitting the state to (N+1) ways is not going to
> > scale. Unless N is of course really small, like 2 or 3 at most.
>
> That's kind of what I imagined - try them all. The A
steakhal wrote:
What's the benefit of using `DRAV` over `RAV`? I couldn't find the motivation
in the PR summary in neither of this or the linked PR.
https://github.com/llvm/llvm-project/pull/115144
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
@@ -748,6 +747,22 @@ SVal CXXInstanceCall::getCXXThisVal() const {
return ThisVal;
}
+const CXXRecordDecl *CXXInstanceCall::getDeclForDynamicType() const {
+ const MemRegion *R = getCXXThisVal().getAsRegion();
+ if (!R)
+return nullptr;
+
+ DynamicTypeInfo DynType = g
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/38
>From d3e8f1fefc06e4bf52adc128b286d3c259aa3151 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Fri, 4 Oct 2024 13:46:09 +0200
Subject: [PATCH 1/3] [analyzer] Use dynamic type when invalidating by a member
f
@@ -330,3 +330,41 @@ void no_crash() {
}
} // namespace crash
+
+namespace array_subscript_initializer {
+struct S {
+ int x;
+};
+
+void no_crash() {
+ S arr[][2] = {{1, 2}};
+
+ const auto [a, b] = arr[0]; // no-crash
steakhal wrote:
My bad. Im too tired
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/114427
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
> [...] I'm a bit confused by the first commit 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's tainted.
Exactly. Because we don't let the bind operations go through, the c
https://github.com/steakhal approved this pull request.
I don't really feel that this is relevant enough to be merged, but let's do it
anyways.
If you find more things to refactor, or have plans for doing so, let me know.
https://github.com/llvm/llvm-project/pull/114427
steakhal wrote:
I held this patch off because during testing I saw some interesting-looking
(seemingly) FPs.
I wanted to have a look, but I couldn't find disputable evidence for proving
that they were FPs.
I still believe that this patch is solid, and even if it exposes some FPs,
those are mor
https://github.com/steakhal closed
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
steakhal wrote:
I wanted to come back with another example:
```c++
int ternary_in_assume(int a, int b) {
[[assume(a > 10 ? b == 4 : b == 10)]];
if (a > 20)
return b + 100; // expecting 104
if (a > 10)
return b + 200; // expecting 204
return b + 300; // expecting 310
}
```
Actuall
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/118096
Like in the test case:
```c++
struct String {
String(const String &) {}
};
struct MatchComponent {
unsigned numbers[2];
String prerelease;
MatchComponent(MatchComponent const &) = default;
};
MatchComp
steakhal wrote:
> The change itself looks good to me, but I wonder what is the reason that we
> only want to do this canonicalization when we access fields?
It took me a while to unwrap your question. Actually, think of it as an
invariant. We should never have reference typed value regions wra
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/117791
>From ed174c8b52880d4f89415eb3a72da13f355438d7 Mon Sep 17 00:00:00 2001
From: einvbri
Date: Mon, 25 Nov 2024 10:31:57 +0100
Subject: [PATCH 01/20] [analyzer] Modernize, improve and promote chroot
checker
This
https://github.com/steakhal approved this pull request.
https://github.com/llvm/llvm-project/pull/117791
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/117791
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
Ping @NagyDonat
https://github.com/llvm/llvm-project/pull/116034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
@Xazax-hun I don't really have the time for this one. Could you take it over?
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-c
@@ -98,9 +98,9 @@ void ChrootChecker::evalChroot(const CallEvent &Call,
CheckerContext &C) const {
const auto *CE = cast(Call.getOriginExpr());
const LocationContext *LCtx = C.getLocationContext();
- NonLoc RetVal =
- SVB.conjureSymbolVal(/*SymbolTag=*/nullptr,
steakhal wrote:
Hi Vince, I figured it's easier if I just push to your branch with my
recommendations.
Let me know if you like it. Challenge it if not.
https://github.com/llvm/llvm-project/pull/117791
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/117791
>From ed174c8b52880d4f89415eb3a72da13f355438d7 Mon Sep 17 00:00:00 2001
From: einvbri
Date: Mon, 25 Nov 2024 10:31:57 +0100
Subject: [PATCH 01/16] [analyzer] Modernize, improve and promote chroot
checker
This
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/118096
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
I simplified your implementation, and also identified a shortcoming of the
`getSpecificAttr` that it didn't work with const attributes. I'll submit a fix
for it separately to this PR.
The implementation looks pretty but there is a catch. And this is unfortunately
a blocker iss
steakhal wrote:
> > I'm not sure I see why. The logs I linked in the revert only showed a
> > single test failure. The new test we added in this PR. This suggests close
> > correlations. Maybe the content of the "constraints" map in the State is
> > dumped in a non-deterministic order? And we
steakhal wrote:
> > @danix800 Could you please have a look at the failed test, such that we
> > could reapply this PR? I reverted this soon after I realized the broken
> > test is from this PR.
>
> The test randomly fails for unknown reason, on VS2019~2022, after
> [1c154bd](https://github.co
1601 - 1700 of 2518 matches
Mail list logo
