[cfe-dev] sizeof(long) in OpenCL C

[Michele Scandale]

On 09/02/2013 10:00 AM, David Tweed wrote:
> On 08/30/2013 07:00 PM, David Tweed wrote:
>> Hi,
>>
>> | I notice that, with the patch applied, "long" has 64 bits, but
>> __INTPTR_TYPE__ is still defined as "long int" on ARM. This is now wrong; it
>> needs to be set to "int" instead. Do you have pointers for
>> | correcting this in clang?
>>
>> Unfortunately not; implementation (even such simple things as choice of
>> size) of pointers for OpenCL devices is one of those "implementations may
>> make different choices" areas where things don't map cleanly to the standard
>> clang front-end.
> 
> | Uhm.. Implementation defined types makes type size enforcing complex. If the
> | mapping must be direct I think there is no solution.
> 
> What I meant was: pointers within the context of OpenCL may not necessarily be implemented in the same way as on the "underlying" target. As such, embedding an assumption that the pointer type is the same within the common clang code is probably the wrong way to do things to be useful as common code. (Of course there it may actually be the same for some ways of implementing OpenCL, just that it need not always be.) I think Erik's later patch introducing a distinct PointerWidth seems like a suitable mechanism.
> 
> | If the relationship is just between implementation defined type and (sign,
> | bitwidth) then the mapping can be done on the fly looking for the pair (sign,
> | bitwidth) in the native types map, picking a compatible type.
> | The fact that there is no direct control on the mapping can be an issue.
> 
> I don't quite understand what you mean here; as above the key thing I was mentioning was that the size of a pointer used when working as a OpenCL compiler may be different from the one that would be chosen when working as a C compiler, so simply making the "C compiler" pointer width expressed in terms of types defined identically in OpenCL and C is not the way to go.

Picking 'size_t' as example: on a 64bit target I would expect that 'size_t' will
be mapped to an unsigned 64bit builtin integer type. If I declare LongWidth =
LongLongWidth = 64 then both 'unsigned long' and 'unsigned long long' would be
valid choice for 'size_t'. Expressing the relationship in a indirect way then
the definition of implementation defined types is not affected by the potential
changes that OpenCL language definition may impose respect to the choice done
for the C compiler.

BTW, it seems that the mapping cannot be just based on size and sign parameters.

Regards,
-Michele

> Cheers,
> Dave
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782
>