bjope added a comment.

In D85191#2196863 <>, @rsmith wrote:

> In D85191#2195923 <>, @ebevhan wrote:
>> In 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?

  rG LLVM Github Monorepo


cfe-commits mailing list

Reply via email to