bjope added a comment. In D85191#2196863 <https://reviews.llvm.org/D85191#2196863>, @rsmith wrote:
> In D85191#2195923 <https://reviews.llvm.org/D85191#2195923>, @ebevhan wrote: > >> In D85191#2193645 <https://reviews.llvm.org/D85191#2193645>, @rsmith wrote: >> >>>> This is not ideal, since it makes the calculations char size dependent, >>>> and breaks for sizes that are not a multiple of the char size. >>> >>> How can we have a non-bitfield member whose size is not a multiple of the >>> size of a char? >> >> Downstream, we have fixed-point types that are 24 bits large, but where the >> char size is 16. The type then takes up 2 chars, where 8 of the bits are >> padding. The only way in Clang to express that the width of the bit >> representation of a type should be smaller than the number of chars it takes >> up in memory -- and consequently, produce an `i24` in IR -- is to return a >> non-charsize multiple from getTypeInfo. > > This violates the C and C++ language rules, which require the size of every > type to be a multiple of the size of char. A type with 24 value bits and 8 > padding bits should report a type size of 32 bits, just like `bool` reports a > size of `CHAR_BIT` bits despite having only 1 value bit, and x86_64 `long > double` reports a type size of 128 bits despite having only 80 value bits. I don't see that it breaks the language rules. The sizeof result for the 24 bit type should be 2 in the target described by @ebevhan (two 16-bit bytes). But I imagine that without this patch it is reported as 24/16=1, right? So isn't the problem that toCharUnitsFromBits is rounding down when given a bitsize that isn't a multiple of CHAR_BIT? Would it perhaps make sense to let it round up instead? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85191/new/ https://reviews.llvm.org/D85191 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
