https://github.com/martinboehme closed
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
martinboehme wrote:
CI failure (DataFlowSanitizer-x86_64 :: release_shadow_space.c) looks unrelated.
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
martinboehme wrote:
> > In summary, if the storage locations for two pointers are the same, we can
> > return a true literal for the comparison, but if the storage locations are
> > different, we need to return an atom.
>
> I am wondering, if it would make sense to "fix up" the state when we d
Xazax-hun wrote:
> In summary, if the storage locations for two pointers are the same, we can
> return a true literal for the comparison, but if the storage locations are
> different, we need to return an atom.
I am wondering, if it would make sense to "fix up" the state when we discover
alia
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ymand approved this pull request.
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
martinboehme wrote:
> I'll change the PR accordingly and will let you know once it's ready for
> another look.
Sorry, this completely fell off my radar. I've finally revisited this now, and
the PR is ready for review again. PTAL.
https://github.com/llvm/llvm-project/pull/75170
___
https://github.com/martinboehme edited
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/martinboehme updated
https://github.com/llvm/llvm-project/pull/75170
>From 0ec84267ca5c76ff733c4a5907df9226260a4a76 Mon Sep 17 00:00:00 2001
From: Martin Braenne
Date: Mon, 6 May 2024 10:06:29 +
Subject: [PATCH] [clang][dataflow] Strengthen pointer comparison.
- Instead
martinboehme wrote:
Finally getting back to this.
The reason this was causing tests to fail is really pretty obvious in
hindsight: Different `StorageLocation`s may alias, so if the `StorageLocation`s
for two `PointerValue`s are different, we can't assume that the pointers must
compare unequal
https://github.com/ymand approved this pull request.
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
martinboehme wrote:
Heads up: I'm holding off on merging this patch because it makes some tests in
the [Crubit nullability
analysis](https://github.com/google/crubit/tree/main/nullability) fail. I'm
still investigating exactly why this is.
https://github.com/llvm/llvm-project/pull/75170
_
Xazax-hun wrote:
> It's probably a good thing for storage locations to have types (because we
> want to be able to model the dynamic type of an object), but this probably
> means that we want to model addresses separately from storage locations.
Our knowledge of the dynamic type might change d
martinboehme wrote:
> An alternative approach would be to do [hash
> consing](https://en.wikipedia.org/wiki/Hash_consing). Since pointer values
> are completely determined by the pointee (for some definition of the pointee,
> e.g., we might have `void*` and `int*` pointers pointing to the same
@@ -152,6 +153,47 @@ TEST_F(EnvironmentTest, JoinRecords) {
}
}
+TEST_F(EnvironmentTest, DifferentReferenceLocInJoin) {
martinboehme wrote:
Agree. The original test case was minimized from a failing assertion, but it
would likely be fiddly to try and recre
@@ -3893,6 +3893,66 @@ TEST(TransferTest, BooleanInequality) {
});
}
+TEST(TransferTest, PointerEquality) {
martinboehme wrote:
Good point -- done.
https://github.com/llvm/llvm-project/pull/75170
___
cfe-comm
https://github.com/martinboehme updated
https://github.com/llvm/llvm-project/pull/75170
>From 32fe6eb51c43e423e50178509a8020d392cd3a42 Mon Sep 17 00:00:00 2001
From: Martin Braenne
Date: Wed, 13 Dec 2023 10:46:43 +
Subject: [PATCH 1/2] [clang][dataflow] Strengthen pointer comparison.
- In
Xazax-hun wrote:
An alternative approach would be to do [hash
consing](https://en.wikipedia.org/wiki/Hash_consing). Since pointer values are
completely determined by the pointee (for some definition of the pointee, e.g.,
we might have `void*` and `int*` pointers pointing to the same storage
@@ -3893,6 +3893,66 @@ TEST(TransferTest, BooleanInequality) {
});
}
+TEST(TransferTest, PointerEquality) {
Xazax-hun wrote:
I think it would be great to add a test case with union members to document the
limitation.
https://github.com/llvm/llvm-proj
https://github.com/Xazax-hun approved this pull request.
This is a massive improvement! Thanks! Looks great to me, I have some not too
important comments inline.
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits
@@ -152,6 +153,47 @@ TEST_F(EnvironmentTest, JoinRecords) {
}
}
+TEST_F(EnvironmentTest, DifferentReferenceLocInJoin) {
Xazax-hun wrote:
While running analysis on C++ code is indirect, it has the advantage of
documenting what code can trigger such behavior
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/75170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (martinboehme)
Changes
- Instead of comparing the identity of the `PointerValue`s, compare the
underlying `StorageLocation`s.
- If the `StorageLocation`s are different, return a definite "false" as the
result of the comparison
https://github.com/martinboehme created
https://github.com/llvm/llvm-project/pull/75170
- Instead of comparing the identity of the `PointerValue`s, compare the
underlying `StorageLocation`s.
- If the `StorageLocation`s are different, return a definite "false" as the
result of the compar
24 matches
Mail list logo
