aaron.ballman added a comment. Drive-by comment before I get into the review: does HLSL intend to follow the standard in terms of behavior of intN_t? If yes, then this doesn't follow the behavior allowed by the standard or the direction WG14 chose. We discussed https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2960.pdf at our Jul 2022 meeting, and this particular topic was part of that paper. The result of the preference poll was:
Opinion poll: Which stdint.h types should be allowed to be bit-precise integer types? 0) Leave it as is - [u]intN_t may not be bit-precise, but [u]intptr_t and [u]intmax_t are unclear. (no one asked for this direction) 1) None of [u]intN_t, [u]intptr_t and [u]intmax_t. 9 / 5 / 4 (this direction) 2) None of [u]intN_t, [u]intptr_t and [u]intmax_t, unless they are wider than int. 7 / 7 / 5 (not this direction) So we decided explicitly to not allow intN_t to be defined in terms of a bit-precise integer type. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133668/new/ https://reviews.llvm.org/D133668 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
