chrish_ericsson_atx added a comment.
In D104285#2836190 <https://reviews.llvm.org/D104285#2836190>, @ASDenysPetrov
wrote:
>> I think the presence of the initializer list in the test case is not
>> necessary to trigger the spurious warnings
>
> Could you please provide some test cases that you think will uncover other
> issues. I'll add them to the test set.
I tested locally with this patch and found that my guess was incorrect-- I
couldn't trigger the incorrect behavior without an initializer list. So I
think your code and testcases are good as they are!
> I also have to mention one point of what this patch do more. Consider next:
>
> int const arr[2][2] = {{1, 2}, {3, 4}}; // global space
> int const *ptr = &arr[0][0];
> ptr[3]; // represented as ConcreteInt(0)
> arr[1][1]; // represented as reg_$0<int Element{Element{arr,1 S64b,int
> [2]},1 S64b,int}>
>
> As you can see, now the access through the raw pointer is more presice as
> through the multi-level indexing. I didn't want to synchronyze those
> retrieved values both to be `reg_$0`. I've seen a way to handle it more
> sophisticatedly.
> I'm gonna do the same for the multi-level indexing (aka `arr[1][2][3]`).
I don't understand -- probably I don't have enough experience with analyzer
state dumps to know what I should find surprising or better in this example.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104285/new/
https://reviews.llvm.org/D104285
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
