Bug in OpenCL debugger

[Alexandre_D_1]

Hello,

I have some problems with the Intel Debugger. Here is below and attached a minimal code where you can find the problem (the site doesn't allow .cl extension, so the file is in cpp extension...).

The thing is, I cannot directly give variable adresses to functions who include barriers... Seeing the simplicity of the code, I think it is a bug of your debugger.

I am running this kernel on Windows 7, with Visual Studio 2010, on Intel Core i7-4800MQ CPU, and with a global and local work size of {1,1}.

Thank you in advance for all the help you could provide.

[cpp]

void testFunction(int *test)
{

// If I delete de barriers, the problem disappears

printf("\tProcessRay , start\n");

barrier(CLK_LOCAL_MEM_FENCE);

printf("\t\ttest value : %i \n", *test);

barrier(CLK_LOCAL_MEM_FENCE);

printf("\tProcessRay , end \n");

barrier(CLK_LOCAL_MEM_FENCE);

return;

}

__kernel void Kernel_Main()
{

int test = 10;
int *test2 = &test;

// When I launch this first test, no problem occurs
printf("Lauching test 1 \n");
barrier(CLK_LOCAL_MEM_FENCE);
testFunction(test2);

// Here, I have an exception of memory reading violation... :-(
printf("Lauching test 2 \n");
barrier(CLK_LOCAL_MEM_FENCE);
testFunction(&test);

}

[/cpp]

[Raghupathi_M_Intel]

I am not able to reproduce the issue. Can you provide the exact steps and maybe your host code too?

Raghu

[Alexandre_D_1]

Thank you for the answer, and sorry for the delay.

I have put the project and some images of what I get in the archives attached.

Alex

[Yuri_K_Intel]

Hi Alex, The issue is reproducible for me, I will submit a ticket and inform you of the investigation results. Thanks, Yuri

[Yuri_K_Intel]

I also noticed, that the issue happens only when a pointer is calculated as a function argument, I mean: testFunction(&test); Using already calculated pointer: int *test2 = &test; testFunction(test2); doesn't produce this issue (no matter how much time testFunction is called). So I hope you will be able to use this solution as a workaround, Thanks, Yuri