sethp wrote: Happy new year!
An update from my end: I've made what feels like good progress on refactoring the implementation to be a little more concise, both in terms of code and dynamic instruction count (especially for large types). There's still a little more I'd like to do there, especially as relates to handling host-target endianness mismatches: and I think at least one more test I need to devise to validate that the implementation handles bit-fields split across a byte boundary correctly. I hope to push that work up soon, but it still feels a little "too early" to be properly respectful of y'all's time. However, in doing that work, I identified an issue with `bool` types (and, probably, bit-precise `_BitInt(N)` types): the work represented here doesn't yet handle them. Instead, it triggers an assertion when the evaluator produces an 8-bit result where the expression wanted 1-bit. I'm working on a fix for that, but doing so requires handling the case when trying to cram something other than a 0 or 1 into a bool, which has a few wrinkles to it. The way I understand `constexpr` is that _if_ it produces a value, then it will match the behavior specified at runtime, but the evaluator can make the principled choice to be incomplete (as previously with bit-casting bit-fields)—is that right? So, if I'm finding cases where the bit-cast wouldn't match the runtime behavior, it'd be possible to refuse to produce a value by producing an error instead? https://github.com/llvm/llvm-project/pull/74775 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
