rsmith added a comment. In D64146#1604717 <https://reviews.llvm.org/D64146#1604717>, @nand wrote:
> > How do you intend to represent pointers cast to integer types? Allocating > > 64 bits of state for a 64-bit integer is insufficient to model that case. > > Is this ever going to be allowed in constexpr? It's not sufficient for this to handle only the things that are allowed in constant expressions; you also need to allow the things that are allowed by Clang's current constant evaluator, which includes this case. There are also constructs that allow arbitrary constant folding within the context of constant expression evaluation (such as a `__builtin_constant_p` conditional). So yes, you need to deal with this. > If that is the case, we'll add a separate type for all integers which are > large enough to hold a pointer, a tagged union indicating whether the value > is a number or a pointer. This would add significant overhead, but I don't > see any other way which can correctly diagnose UB when casting a random > integer to a pointer. These cases are likely to be rare enough that separately-allocated storage for this case could work. You'll need at least one bit somewhere to track whether you're in the "pointer cast to integer" case, though. (You also need to be able to distinguish between an integer value and an uninitialized integer and an out-of-lifetime integer, so you'll presumably need some side-table to track the state of subobjects anyway.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64146/new/ https://reviews.llvm.org/D64146 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
