Inconsistent types used to represent bitwidth

Clang Frontend
1

Hi all,

I'm currently trying to remove some of the warnings spit out on me by the
VC++ compiler (mostly warnings about possible loss of precision) and
recognized, that the bitwith (size of a type in bits) is represented using
different types all over the place: sometimes unsigned, sometimes uint32_t
and sometimes it's even uint64_t. I really would like to change that to a
more consistent scheme, but need some advice which type to choose. Since I
think we can't expect to get anything terribly large as the bitwidth of a
type I'ld say let's go for uint32_t.

Any comments?
Regards Hartmut

2

Hi Hartmut,

We should go with uint64_t in general. There can be large arrays (for example) on 64-bit targets that need this. For "known little things" like integer types, uint32_t would be sufficient, but it is probably better to be consistent and use uint64_t for everything.

-Chris

3

Chris,

> I'm currently trying to remove some of the warnings spit
out on me by
> the
> VC++ compiler (mostly warnings about possible loss of precision) and
> recognized, that the bitwith (size of a type in bits) is
represented
> using different types all over the place: sometimes unsigned,
> sometimes uint32_t and sometimes it's even uint64_t. I really would
> like to change that to a more consistent scheme, but need
some advice
> which type to choose.
> Since I
> think we can't expect to get anything terribly large as the
bitwidth
> of a type I'ld say let's go for uint32_t.

Hi Hartmut,

We should go with uint64_t in general. There can be large
arrays (for example) on 64-bit targets that need this. For
"known little things" like integer types, uint32_t would be
sufficient, but it is probably better to be consistent and
use uint64_t for everything.

IIUC, the bitwidth is most of the time the number of bits needed to
represent the size, i.e. 32 for uint32_t. In this case 64 is the largest
number these kind of variables will ever hold, no?

Regards Hartmut

4

Yes, except that what is the size of "uint32_t[100000000000LL]" ?

-Chris

5

Chris,

>>> I'm currently trying to remove some of the warnings spit
>> out on me by
>>> the
>>> VC++ compiler (mostly warnings about possible loss of
precision) and
>>> recognized, that the bitwith (size of a type in bits) is
>> represented
>>> using different types all over the place: sometimes unsigned,
>>> sometimes uint32_t and sometimes it's even uint64_t. I
really would
>>> like to change that to a more consistent scheme, but need
>> some advice
>>> which type to choose.
>>> Since I
>>> think we can't expect to get anything terribly large as the
>> bitwidth
>>> of a type I'ld say let's go for uint32_t.
>>
>> Hi Hartmut,
>>
>> We should go with uint64_t in general. There can be large arrays
>> (for example) on 64-bit targets that need this. For "known little
>> things" like integer types, uint32_t would be sufficient,
but it is
>> probably better to be consistent and use uint64_t for everything.
>
> IIUC, the bitwidth is most of the time the number of bits needed to
> represent the size, i.e. 32 for uint32_t. In this case 64 is the
> largest number these kind of variables will ever hold, no?

Yes, except that what is the size of "uint32_t[100000000000LL]" ?

   sizeof(uint32_t[100000000000LL]) < 2^64,

so the size is representable with 64 bits, which means the corresponding
bitwidth is not even '64', which conveniently fits into a int8_t.

But probably I'm getting something really wrong here.
Regards Hartmut

6

>
> IIUC, the bitwidth is most of the time the number of bits needed to
> represent the size, i.e. 32 for uint32_t. In this case 64 is the
> largest number these kind of variables will ever hold, no?

Yes, except that what is the size of "uint32_t[100000000000LL]" ?

   sizeof(uint32_t[100000000000LL]) < 2^64,

so the size is representable with 64 bits, which means the corresponding
bitwidth is not even '64', which conveniently fits into a int8_t.

But probably I'm getting something really wrong here.
Regards Hartmut

I think we lost the correct definition of bitwith along the way. quoting earlier post from this thread:

>>> recognized, that the bitwith (size of a type in bits) is

for me, bitwith( X ) == 8*sizeof( X )

If we speak of the same things, this was done in order to thread the size of bitfield member in an uniform manner with other 'normal' variable.

regards,

7

Yep, exactly!

-Chris

8

Cedric,

>> > IIUC, the bitwidth is most of the time the number of
bits needed to
>> > represent the size, i.e. 32 for uint32_t. In this case 64 is the
>> > largest number these kind of variables will ever hold, no?
>>
>> Yes, except that what is the size of "uint32_t[100000000000LL]" ?
>
> sizeof(uint32_t[100000000000LL]) < 2^64,
>
> so the size is representable with 64 bits, which means the
> corresponding bitwidth is not even '64', which conveniently
fits into a int8_t.
>
> But probably I'm getting something really wrong here.
> Regards Hartmut

I think we lost the correct definition of bitwith along the way.
quoting earlier post from this thread:

> >>> recognized, that the bitwith (size of a type in bits) is

for me, bitwith( X ) == 8*sizeof( X )

If bitwidth is 8*sizeof(X), then you're right and I apologize for the
confusion.

If we speak of the same things, this was done in order to
thread the size of bitfield member in an uniform manner with
other 'normal'
variable.

Hmmm. Obviously I'm lost here or I'm mixing something up. (Please disregard
my statement you quoted above if it increases the confusion)
The point is, that if I'm looking at

clang/Basic/TargetInfo.h:+140:

  /// getLongInfo - Return the size of 'signed long' and 'unsigned long' for
  /// this target, in bits.
  void getLongInfo(uint64_t &Size, unsigned &Align, SourceLocation Loc) {
    Size = Align = 32; // FIXME: implement correctly: wrong for
ppc64/x86-64
  }

  /// getLongLongInfo - Return the size of 'signed long long' and
  /// 'unsigned long long' for this target, in bits.
  void getLongLongInfo(uint64_t &Size, unsigned &Align,
                            SourceLocation Loc) {
    Size = Align = 64; // FIXME: implement correctly.
  }

we use uint64_t for storing numbers which will have the max value of '64',
no?

Does this mean we need 64 bits to represent the _size_ of the variable or
does this mean we need 64 bits to represent the variable itself?

And sorry again for the noise.
Regards Hartmut

9

Chris,

>>>>> recognized, that the bitwith (size of a type in bits) is
>
> for me, bitwith( X ) == 8*sizeof( X )
>
> If we speak of the same things, this was done in order to
thread the
> size of bitfield member in an uniform manner with other 'normal'
> variable.

Yep, exactly!

Ok got it. I simply was heading in the wrong direction.
Thanks for clarifying. I'll change the code base to use uint64_t for this
all over the place then.

Regards Hartmut