Author: Balazs Benics
Date: 2020-04-09T16:06:32+02:00
New Revision: 30e5c7e82fa1c5318540feb83d54757c632e2599
URL:
https://github.com/llvm/llvm-project/commit/30e5c7e82fa1c5318540feb83d54757c632e2599
DIFF:
https://github.com/llvm/llvm-project/commit/30e5c7e82fa1c5318540feb83d54757c632e2599.diff
Author: Balazs Benics
Date: 2020-07-13T14:29:47+02:00
New Revision: d96a47c61625f853ec42a151ae3783e30a3943f3
URL:
https://github.com/llvm/llvm-project/commit/d96a47c61625f853ec42a151ae3783e30a3943f3
DIFF:
https://github.com/llvm/llvm-project/commit/d96a47c61625f853ec42a151ae3783e30a3943f3.diff
Author: Balazs Benics
Date: 2020-06-29T16:54:17+02:00
New Revision: e22cae32c5c4cf8c49b674cea34c105a6cb015f9
URL:
https://github.com/llvm/llvm-project/commit/e22cae32c5c4cf8c49b674cea34c105a6cb015f9
DIFF:
https://github.com/llvm/llvm-project/commit/e22cae32c5c4cf8c49b674cea34c105a6cb015f9.diff
Author: Balazs Benics
Date: 2020-06-29T18:18:43+02:00
New Revision: fe0a555aa3c6f37a5b5d79942215b07587893efa
URL:
https://github.com/llvm/llvm-project/commit/fe0a555aa3c6f37a5b5d79942215b07587893efa
DIFF:
https://github.com/llvm/llvm-project/commit/fe0a555aa3c6f37a5b5d79942215b07587893efa.diff
Author: Balazs Benics
Date: 2020-06-29T18:51:24+02:00
New Revision: de361df3f6d0f20bf16a8deb9e6219556d028b81
URL:
https://github.com/llvm/llvm-project/commit/de361df3f6d0f20bf16a8deb9e6219556d028b81
DIFF:
https://github.com/llvm/llvm-project/commit/de361df3f6d0f20bf16a8deb9e6219556d028b81.diff
Author: Balazs Benics
Date: 2020-07-31T10:28:14+02:00
New Revision: 63d3aeb529a7b0fb95c2092ca38ad21c1f5cfd74
URL:
https://github.com/llvm/llvm-project/commit/63d3aeb529a7b0fb95c2092ca38ad21c1f5cfd74
DIFF:
https://github.com/llvm/llvm-project/commit/63d3aeb529a7b0fb95c2092ca38ad21c1f5cfd74.diff
Author: Balazs Benics
Date: 2022-09-13T08:58:46+02:00
New Revision: f8643a9b31c4029942f67d4534c9139b45173504
URL:
https://github.com/llvm/llvm-project/commit/f8643a9b31c4029942f67d4534c9139b45173504
DIFF:
https://github.com/llvm/llvm-project/commit/f8643a9b31c4029942f67d4534c9139b45173504.diff
Author: Balazs Benics
Date: 2022-09-13T08:58:46+02:00
New Revision: afcd862b2e0a561bf03b1e7b83e6eec8e7143098
URL:
https://github.com/llvm/llvm-project/commit/afcd862b2e0a561bf03b1e7b83e6eec8e7143098
DIFF:
https://github.com/llvm/llvm-project/commit/afcd862b2e0a561bf03b1e7b83e6eec8e7143098.diff
Author: Balazs Benics
Date: 2022-09-13T09:04:27+02:00
New Revision: 7cddf9cad18a65217c8ba0661fefcf78d841a16b
URL:
https://github.com/llvm/llvm-project/commit/7cddf9cad18a65217c8ba0661fefcf78d841a16b
DIFF:
https://github.com/llvm/llvm-project/commit/7cddf9cad18a65217c8ba0661fefcf78d841a16b.diff
Author: Balazs Benics
Date: 2022-09-14T16:45:44+02:00
New Revision: b8e1da050673470f20a75d4ecca2c0a00d1a8691
URL:
https://github.com/llvm/llvm-project/commit/b8e1da050673470f20a75d4ecca2c0a00d1a8691
DIFF:
https://github.com/llvm/llvm-project/commit/b8e1da050673470f20a75d4ecca2c0a00d1a8691.diff
steakhal wrote:
> @DonatNagyE The most straightforward issue that I see is that (if I
> understand the code correctly) the intersected constraint (the value of the
> variable `Constraint` at the end of
> `handleEquivalentAlternativeSymOperands()`) is just discarded after checking
> that it's
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/71284
>From 92ece501b340c3a2a52b5a4614ddb70bb3e35c93 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 4 Nov 2023 13:44:28 +0100
Subject: [PATCH 1/3] [analyzer][solver] On SymSym RelOps, check EQClass
members f
@@ -492,11 +492,13 @@ void check_required_cast() {
void check_cast_behavior(OSObject *obj) {
OSArray *arr1 = OSDynamicCast(OSArray, obj);
- clang_analyzer_eval(arr1 == obj); // expected-warning{{TRUE}}
-// expected-note@-1{{TRUE}}
-
https://github.com/steakhal approved this pull request.
LGTM, but please wait for @DonatNagyE to have a look.
BTW I noticed that the note messages are not tested, but I'm okay to not test
that I think.
https://github.com/llvm/llvm-project/pull/71373
_
https://github.com/steakhal requested changes to this pull request.
I find this alternative less idiomatic (dissimilar to how we implement checks
in other checkers), thus I find this less readable.
I'm okay with that amount of redundancy as it was present.
https://github.com/llvm/llvm-project/p
steakhal wrote:
> > So, if I understand you correctly, at the 3rd if statement, we should
> > canonicalize the symbol we are constraining by walking every sub-symbol and
> > substituting it with its equivalent counterpart (if any), by basically with
> > its eqclass' representative symbol.
>
>
steakhal wrote:
My take is that the z3-based solver is crashing all over the place. So its not
just slower. We anyways don't have CI checks for it.
Given all these, I'd rather not put more burden to the issue tracker regarding
this. I'd consider it if these issues wouldn't be present though, bu
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
steakhal wrote:
> (Force pushed the branch because I wanted to rebase it onto a recent main and
> fix the merge conflicts. Is there a better workflow than this?)
I think git also offers conflict resolution for `git merge origin/main`. It
shoul
https://github.com/steakhal commented:
I would agree with @isuckatcs, and I'd be weak against this PR.
Right now I don't see the benefit of asserting this.
Consider downstream users that might use this reporting system and have their
own trackers. (We don't at Sonar, but pretend), then they woul
@@ -492,11 +492,13 @@ void check_required_cast() {
void check_cast_behavior(OSObject *obj) {
OSArray *arr1 = OSDynamicCast(OSArray, obj);
- clang_analyzer_eval(arr1 == obj); // expected-warning{{TRUE}}
-// expected-note@-1{{TRUE}}
-
=?utf-8?q?G=C3=A1bor?= Spaits,Gabor Spaits ,Gabor
Spaits ,Gabor Spaits
Message-ID:
In-Reply-To:
steakhal wrote:
Yes, why not..
https://github.com/llvm/llvm-project/pull/66481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/steakhal approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/70540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
This is a brief summary of my recent investigation, no direct action is
required.
I had a quick look at the issue differences between clang-17 and llvm/main as a
preparation for the clang-18 release in early January and noticed that because
of this patch, we have some unexpect
https://github.com/steakhal requested changes to this pull request.
I must admit that I didn't look at the issue too much, but this patch speaks
for itself.
Clean, to the point, and meets our conventions. Kudos.
I only have minor remarks.
And be sure to mention `Fixes #70464` in the PR/commit m
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1222,6 +1222,15 @@ void ExprEngine::ProcessInitializer(const CFGInitializer
CFGInit,
PostInitializer PP(BMI, FieldLoc.getAsRegion(), stackFrame);
evalBind(Tmp, Init, Pred, FieldLoc, InitVal, /*isInit=*/true, &PP);
}
+ } else if (BMI->isBaseInitializer() &&
@@ -0,0 +1,69 @@
+// Refer issue 70464 for more details.
+//
+// When the base class does not have a declared constructor, the base
+// initializer in the constructor of the derived class should use the given
+// initializer list to finish the initialization of the base class.
+//
@@ -0,0 +1,69 @@
+// Refer issue 70464 for more details.
+//
+// When the base class does not have a declared constructor, the base
+// initializer in the constructor of the derived class should use the given
+// initializer list to finish the initialization of the base class.
+//
@@ -1222,6 +1222,15 @@ void ExprEngine::ProcessInitializer(const CFGInitializer
CFGInit,
PostInitializer PP(BMI, FieldLoc.getAsRegion(), stackFrame);
evalBind(Tmp, Init, Pred, FieldLoc, InitVal, /*isInit=*/true, &PP);
}
+ } else if (BMI->isBaseInitializer() &&
@@ -0,0 +1,69 @@
+// Refer issue 70464 for more details.
+//
+// When the base class does not have a declared constructor, the base
+// initializer in the constructor of the derived class should use the given
+// initializer list to finish the initialization of the base class.
+//
@@ -0,0 +1,69 @@
+// Refer issue 70464 for more details.
steakhal wrote:
Feel free to put a full link if you want.
https://github.com/llvm/llvm-project/pull/70792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,69 @@
+// Refer issue 70464 for more details.
+//
+// When the base class does not have a declared constructor, the base
+// initializer in the constructor of the derived class should use the given
+// initializer list to finish the initialization of the base class.
+//
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,16 @@
+// RUN: %clang_analyze_cc1 -fno-builtin
-analyzer-checker=core,alpha.unix.Stream -verify %s
+// expected-no-diagnostics
+
+typedef struct _FILE FILE;
+
+// These functions are not standard C library functions.
+FILE *tmpfile(const char *restrict path);
+FILE *fo
https://github.com/steakhal requested changes to this pull request.
Still looks good to me.
I recommended a couple comments here and there to clarify the intent of the
test, and to raise awareness.
I'd suggest to reword the PR title (and the commit title ofc) to something like
`[analyzer] Restr
@@ -0,0 +1,16 @@
+// RUN: %clang_analyze_cc1 -fno-builtin
-analyzer-checker=core,alpha.unix.Stream -verify %s
+// expected-no-diagnostics
+
+typedef struct _FILE FILE;
+
+// These functions are not standard C library functions.
+FILE *tmpfile(const char *restrict path);
+FILE *fo
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -174,9 +176,119 @@ compareValueToThreshold(ProgramStateRef State, NonLoc
Value, NonLoc Threshold,
return {nullptr, nullptr};
}
-void ArrayBoundCheckerV2::checkLocation(SVal location, bool isLoad,
-
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70056
___
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:
@@ -174,9 +176,119 @@ compareValueToThreshold(ProgramStateRef State, NonLoc
Value, NonLoc Threshold,
return {nullptr, nullptr};
}
-void ArrayBoundCheckerV2::checkLocation(SVal location, bool isLoad,
-
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal requested changes to this pull request.
Looks good. I only have minor remarks.
Consider renaming the PR `Improve reports` -> `Improve messages`, or
`diagnostics`, to highlight that the "messages" aspect is improved, n
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -174,9 +176,119 @@ compareValueToThreshold(ProgramStateRef State, NonLoc
Value, NonLoc Threshold,
return {nullptr, nullptr};
}
-void ArrayBoundCheckerV2::checkLocation(SVal location, bool isLoad,
-
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -174,9 +176,119 @@ compareValueToThreshold(ProgramStateRef State, NonLoc
Value, NonLoc Threshold,
return {nullptr, nullptr};
}
-void ArrayBoundCheckerV2::checkLocation(SVal location, bool isLoad,
-
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -174,9 +176,119 @@ compareValueToThreshold(ProgramStateRef State, NonLoc
Value, NonLoc Threshold,
return {nullptr, nullptr};
}
-void ArrayBoundCheckerV2::checkLocation(SVal location, bool isLoad,
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/70837
Workaround the case when the `this` pointer is actually a `NonLoc`, by
returning `Unknown` instead.
The solution isn't ideal, as `this` should be really a `Loc`, but due to how
casts work, I feel this is our ea
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -217,80 +326,71 @@ void ArrayBoundCheckerV2::checkLocation(SVal location,
bool isLoad,
// MallocChecker that call SValBuilder::getConjuredHeapSymbolVal()) and
// non-symbolic regions (e.g. a
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
I only had a couple `std::move`s missing, an FYI comment, and one question
about the diagnostics in the tests.
Even in the current state, I think it's a good baby
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -174,9 +176,116 @@ compareValueToThreshold(ProgramStateRef State, NonLoc
Value, NonLoc Threshold,
return {nullptr, nullptr};
}
-void ArrayBoundCheckerV2::checkLocation(SVal location, bool isLoad,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -217,80 +326,71 @@ void ArrayBoundCheckerV2::checkLocation(SVal location,
bool isLoad,
// MallocChecker that call SValBuilder::getConjuredHeapSymbolVal()) and
// non-symbolic regions (e.g. a
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -217,80 +326,71 @@ void ArrayBoundCheckerV2::checkLocation(SVal location,
bool isLoad,
// MallocChecker that call SValBuilder::getConjuredHeapSymbolVal()) and
// non-symbolic regions (e.g. a
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -0,0 +1,149 @@
+// RUN: %clang_analyze_cc1 -Wno-array-bounds -analyzer-output=text\
+// RUN:
-analyzer-checker=core,alpha.security.ArrayBoundV2,unix.Malloc,alpha.security.taint
-verify %s
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -22,23 +22,25 @@
#include "clang/StaticAnalyzer/Core/PathSensitive/DynamicExtent.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
#include "llvm/ADT/SmallString.h"
+#include "llvm/S
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -1222,6 +1222,15 @@ void ExprEngine::ProcessInitializer(const CFGInitializer
CFGInit,
PostInitializer PP(BMI, FieldLoc.getAsRegion(), stackFrame);
evalBind(Tmp, Init, Pred, FieldLoc, InitVal, /*isInit=*/true, &PP);
}
+ } else if (BMI->isBaseInitializer() &&
https://github.com/steakhal approved this pull request.
Looks great!
FYI when submitting patches to GH try not to force-push to help the UI for
following lines having comments. Otherwise, they will be marked as "outdated"
and become hard to dig up and relate to new line locations. This was eas
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/70837
>From a7f64815f4986fad597b9cb2d1acce2de9ac20bf Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 23 Oct 2023 18:10:29 +0200
Subject: [PATCH 1/2] [analyzer] Fix assertion failure in
CXXInstanceCall::getCXX
steakhal wrote:
> Hmm, I wonder if we should leave a FIXME comment, but it looks good to me.
I was thinking where to put the FIXME, and as I explored that should be within
the CastVisitor. After that, I argued, that then I should still have the
(ineffective) `SVB.evalCast()` to actually exerci
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/70837
___
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/70837
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
> > WDYT?
>
> I like this! I hope we do not add too much redundant work, but at least we
> make it clear what is the plan to fix this in the future.
Please approve the PR again, so that I could merge this after I give some time
for others to look at this.
https://github.com/l
https://github.com/steakhal approved this pull request.
https://github.com/llvm/llvm-project/pull/70540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal approved this pull request.
You are right.
I'm not sure it improves the code too much, and I wonder if you have further
ideas refactoring the checker; if so we could probably bundle up similar
changes into this one.
https://github.com/llvm/llvm-project/pull/70927
__
@@ -0,0 +1,16 @@
+// RUN: %clang_analyze_cc1 -fno-builtin
-analyzer-checker=core,alpha.unix.Stream -verify %s
+// expected-no-diagnostics
+
+typedef struct _FILE FILE;
+
+// These functions are not standard C library functions.
+FILE *tmpfile(const char *restrict path); // Real '
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/71039
The goal of this patch is to refine how the `SVal` base and sub-kinds are
represented by forming one unified enum describing the possible SVals. This
means that the `unsigned SVal::Kind` and the attached bit-pa
steakhal wrote:
This PR relates to #69835
([comment](https://github.com/llvm/llvm-project/issues/69835#issuecomment-1775533393)).
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
steakhal wrote:
> But I have to point out that this patch doesn't address the fact that `const
> void* Data` is not friendly to debuggers, especially with type information
> encoded in another member. So even with this patch applied, someone would
> still have to write (and maintain) a custom
steakhal wrote:
I wanted to highlight that this PR resolved a bunch of open issues, namely:
#61919, #59493, #54533
Thank you!
So I think we should mention this in the release notes for clang-18 in some
way. I'll keep this in mind.
https://github.com/llvm/llvm-project/pull/70792
__
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -0,0 +1,149 @@
+// RUN: %clang_analyze_cc1 -Wno-array-bounds -analyzer-output=text\
+// RUN:
-analyzer-checker=core,alpha.security.ArrayBoundV2,unix.Malloc,alpha.security.taint
-verify %s
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -217,80 +326,71 @@ void ArrayBoundCheckerV2::checkLocation(SVal location,
bool isLoad,
// MallocChecker that call SValBuilder::getConjuredHeapSymbolVal()) and
// non-symbolic regions (e.g. a
steakhal wrote:
> As #59493 is an array, which is different from the test case I provided and
> the ones in #61919 and #54533, although this pr can correctly handle the
> array case, do I still need to add the array one to the test case?
It would be really nice if you could. Thanks!
https:/
steakhal wrote:
> Do I need to
>
> * create a new PR?
>
> * push directly to this PR on the original branch `Snape3058:issue-70464`?
>
> * commit directly without revision?
>
>
> Which operation is correct?
>
> (Sorry for not familiar with GitHub) -(
I'd prefer a new PR, and me
@@ -66,3 +66,23 @@ struct Derived : Base {
void entry() { Derived test; }
} // namespace delegate_ctor_call
+
+// Additional test case from issue #59493
+namespace init_list_array {
+
+struct Base {
+ int foox[1];
steakhal wrote:
I'd suggest a more realistic
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/71073
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/71073
___
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/71073
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal approved this pull request.
Thanks
https://github.com/llvm/llvm-project/pull/71073
___
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/71039
>From 3bc43ab005aa76a43644d4d93286215b490cc8fa Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 2 Nov 2023 10:21:03 +0100
Subject: [PATCH 1/2] [analyzer][NFC] Rework SVal kind representation
The goal of
steakhal wrote:
> But I have to point out that this patch doesn't address the fact that `const
> void* Data` is not friendly to debuggers, especially with type information
> encoded in another member. So even with this patch applied, someone would
> still have to write (and maintain) a custom
@@ -30,3 +30,24 @@ void test(int i) {
clang_analyzer_dump(g4);
// expected-warning@-1 {{&i [as 64 bit integer]}}
}
+
+struct A {
+ int n;
+ void set(int x) {
+n = x;
+ }
+};
+using ptr_size = decltype(sizeof(void *));
+void gh_69922(ptr_size p) {
+ // expected-warni
@@ -30,3 +30,24 @@ void test(int i) {
clang_analyzer_dump(g4);
// expected-warning@-1 {{&i [as 64 bit integer]}}
}
+
+struct A {
+ int n;
+ void set(int x) {
+n = x;
+ }
+};
+using ptr_size = decltype(sizeof(void *));
steakhal wrote:
Fixed. Now usin
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/70837
>From 2de19fc8e14319674ce87c18771ba1b8ba22f79b Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Mon, 23 Oct 2023 18:10:29 +0200
Subject: [PATCH 1/3] [analyzer] Fix assertion failure in
CXXInstanceCall::getCXX
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/70837
___
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/71284
The idea is that if we see a `X RELOP Y` being constrained to a RangeSet `S`,
then check the eqclasses of X and Y respectively and for `X' RELOP Y'`
SymSymExprs and try to infer their ranges.
If there is no con
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/71039
>From 8f16d3000a91df33d416dd09381175ddeb7e5ed3 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Sat, 4 Nov 2023 15:25:42 +0100
Subject: [PATCH] [analyzer][NFC] Rework SVal kind representation
The goal of this
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/71039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
For crossreference: I raised some related questions around having void casts
artificially keeping constraints and symbols alive at discuss:
https://discourse.llvm.org/t/range-based-solver-and-eager-symbol-garbage-collection/74670
https://github.com/llvm/llvm-project/pull/71284
_
steakhal wrote:
> I think every time we need to iterate over all member of an equivalence
> class, we might do something wrong. The point of the equivalence class would
> be to make sure those elements are equivalent. One way to avoid iteration
> would be to always use the representative of th
steakhal wrote:
Thanks for the replies.
I'll come back to this PR once I have some time; maybe during the holidays.
Both assertions directly relate to this PR for sure.
> I looked into Tom's bug report and I hit the following assertion in a debug
> build:
>
> ```
> clang:
> /srv/repos/llvm-pr
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
steakhal wrote:
I'm in favor of this change. I'll pull the patch downstream and report back how
it performed.
Coming back to the `&array[size]` example, actually I believ
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
Overall, I'm in favor of this change.
On the other hand, I'd urge for not to regress on the diagnostics.
To me, `alloca` is like a VLA; which is prone to misuses, th
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/72107
___
cfe-commits mailing list
cfe-commits@lis
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
steakhal wrote:
FYI I edited the PR summary so that I'm not tagged there directly because if
someone is tagged in a commit message on GH, that person will be notified eac
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
steakhal wrote:
> @steakhal thanks for the checking and sorry for the unintentional spamming.
>
> > Such a great feature, right?
>
> Just wonderful 😄
To clarify, you di
https://github.com/steakhal approved this pull request.
The patch makes sense to me.
https://github.com/llvm/llvm-project/pull/74141
___
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 ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/72107
__
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
Sorry for reporting back only after a week or so. The analysis wa
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -413,6 +464,19 @@ bool ArrayBoundCheckerV2::isFromCtypeMacro(const Stmt *S,
ASTContext &ACtx) {
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/74345
Review the commits one by one. I plan to merge them manually by pushing both of
these at once.
This PR intends to fix #74269.
>From 1359a7ef528358cc7e10a751aa885c6bd8ac8d1c Mon Sep 17 00:00:00 2001
From: Balazs
https://github.com/steakhal milestoned
https://github.com/llvm/llvm-project/pull/76446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 2340 matches
Mail list logo
