mboehme added a comment. In D152813#4420445 <https://reviews.llvm.org/D152813#4420445>, @gribozavr2 wrote:
> In D152813#4420399 <https://reviews.llvm.org/D152813#4420399>, @mboehme wrote: > >> It looks to me as if the values we're now newly producing for integer >> literals are causing non-convergence of the analysis on the for-loop. > > For integer literals specifically, we should be returning the same value for > the same literal over multiple loop iterations. And also, ideally, for > multiple equal literals, too, so that an integer literal "42", no matter how > many times spelled in the program, creates the same symbolic value. That's true, and I'll modify the patch so that we do this. (I should probably also include a test that checks that `42 == 42` is equivalent to `true`.) But even without this, wouldn't we expect the analysis to converge? The way I'm treating integer literals right now, the analysis is in effect "seeing" the example I quoted above like this: int return_some_random_int(); void multiple_unchecked_accesses(absl::optional<int> opt1, absl::optional<int> opt2) { for (int i = return_some_random_int(); i < return_some_random_int(); i++) { opt1.value(); // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: unchecked access to optional } opt2.value(); // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: unchecked access to optional value } We would expect analysis of this code to converge too -- right? So I think the problem we're seeing here is independent of how we treat integer literals specifically (though I agree the same integer literal should always be represented by the same `Value`). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152813/new/ https://reviews.llvm.org/D152813 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
