[cfe-dev] Got compile error 'comparison between non-overlapping address spaces' on 3.6 branch

Sameer Sahasrabuddhe sameer.sahasrabuddhe at amd.com
Thu Feb 12 22:17:07 PST 2015


Hello Ruiling,

As far as I can see, the C spec defines the literal "0" as the null 
pointer, so the following macro seems better:

#define NULL 0

But ignoring the NULL, I think the behaviour might change between OpenCL 
1.2 and OpenCL 2.0. In CL12, the "void *" is likely to be a pointer to 
the private address space. In that case, the comparison is undefined. In 
CL20, it is likely to be a pointer to the generic address space, and it 
should be allowed by the frontend. (Because generic address space 
includes global address space).

I have to use words like "should" and "likely to" because this needs 
confirmation from language lawyers ... the question actually pushes the 
boundaries of how much I understand the details of OpenCL! :)

Sameer.

On 2/13/2015 11:25 AM, Song, Ruiling wrote:
> Hi Sameer, Anastasia,
>
> Do you have any comment on this? Thanks!
>
> Ruiling
>> -----Original Message-----
>> From: Song, Ruiling
>> Sent: Wednesday, February 11, 2015 10:38 AM
>> To: 'cfe-dev at cs.uiuc.edu'
>> Subject: Got compile error 'comparison between non-overlapping address
>> spaces' on 3.6 branch
>>
>> I am a developer working on Beignet (OpenCL driver for Intel Graphics card).
>> I am trying Clang 3.6 branch, and encounter below problem. It works well in
>> older clang version.
>> We define NULL as "#define NULL (void *)0", so user could directly use it in
>> OpenCL language like __kernel void test(__global unsigned int *dst)
>> 	if (dst != NULL) {do something;}
>> }
>> But I got below error when compiling using clang 3.6.
>> "error: comparison between  ('__global unsigned int *' and 'void *') which
>> are pointers to non-overlapping address spaces"
>>
>> Is this the expected behavior or a bug?
>>
>> Thanks!
>> Ruiling


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150213/df2dc7e5/attachment.html>


More information about the cfe-dev mailing list