Re: How to clear compile error when using rdrand64_step due to typedef'ing a 64-bit type?

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 19 August 2016 at 08:48, Jonathan Wakely wrote:
> On 19 August 2016 at 07:53, Jeffrey Walton wrote:
>>>> Forgive my ignorance... 'unsigned long' is 64 bits, which is what that
>>>> interface needs (if I am reading the docs correctly).
>>>
>>> The functions takes a pointer to an unsigned 64-bit type, not
>>> necessarily unsigned long.
>>
>> Thanks again Jonathon. I guess this is what I don't quite
>> understand... From the preprocessor, GCC tells me the UINT64 type is
>> the following on x86_64:
>>
>>     #define __UINT64_TYPE__ long unsigned int
>>
>> If 'long unsigned int' is the 64-bit integer and it meets alignment
>
> It's not *the* 64-bit integer, it's *a* 64-bit integer.
>
> On LP64 platforms

Oops, sorry for the incomplete sentence. I meant to say:

On LP64 platforms unsigned long has the same representation as
unsigned long long, but it's still a separate type.

On ILP32 platforms unsigned long has the same representation as
unsigned int, but it's still a separate type.

A char has the same representation as one of signed char or unsigned
char, but it's still a separate type.

>> and size requirements (as a 'minimum' of sorts), then why can't it be
>> used where the 64-bit type is required (i..e, the pointer in the call
>> to _rdrand64_step).
>
> Because that's how the C++ type system works.
>
> __UINT64_TYPE__ is the underlying type of uint64_t. The signature for
> the function you're calling is:
>
> ../gcc/config/i386/immintrin.h:_rdrand64_step (unsigned long long *__P)
>
> That's not uint64_t, so don't try to use uint64_t. Use the type the
> function is declared to take.
>
> The rules of C++ don't say you can freely mix pointers to distinct
> types as long as they are a bit samey. You can't mix int* and long*
> when sizeof(long) == sizeof(int) and you can't mix unsigned long long*
> and unsigned long* when sizeof(unsigned long long) == sizeof(unsigned
> long).
>
> You've basically gone chasing after some unrelated definition (that of
> uint64_t) which has nothing to do with _rdrand64(), looking at
> unrelated implementation details of that different type, and the
> simple solution is to just use the type in the function declaration.