martong added a comment. In D115149#3181580 <https://reviews.llvm.org/D115149#3181580>, @NoQ wrote:
> Like, that's the whole reason why `nonloc::LocAsInteger` exists: so that we > could cast a pointer to an integer and actually have a way to represent the > resulting value as `NonLoc`. > I'm confident that there's a way to get it right, simply because the program > under analysis is type-correct. If it's the simplifier, let's fix the > simplifier. If the original value is not verbose enough, let's fix the > original value. But I really think we should keep this assertion working > 24/7. I'm sure when you find the root cause it'll all make sense to you. OK. Actually, we do create an SVal for the pointer-to-integer cast that is indeed an `LocAsInteger`. However, we loose this information when we build up the symbol tree in `SValBuilder::makeSymExprValNN`. I think, the only way to preserve this information is to create a `SymbolCast` node in the symbol tree. So, later the SValBuilder can build-up the correct SVal that represents the cast properly even when the symbol is constrained. I have created a new child patch that reverts this patch and which creates the SymbolCast. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115149/new/ https://reviews.llvm.org/D115149 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
