OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.

IOC64.exe always crashes for a specific program on specific Intel Processor


We are facing a wierd issue with OpenCL SDK:

We have two very complex OpenCL programs and that we are building using ioc64.exe on various Intel based machines. So far the work was developed using slightly older Core i7 laptops.. all i7-4720HQ or others from the same generation.

We are using Intel® SDK for OpenCL™ Applications version 2017 R2 (latest) On windows 10.  We are compiling for CPU (-device=CPU). This was all working fine on those old laptops. Then we decided to try this on an intel NUC with Intel Core i7-6770HQ and we found that ioc64.exe consistently crashes during the following command  

ioc64 -device=CPU

while it works fine on the same machine for other program i.e

ioc64 -device=CPU   passes without any crash. 

We got curious and tried them on a brand new MSI Laptop with 7th gen Core -i7 still the same result. build for crashes the compiler but def passes fine. and yet on older laptops all is well. 

With more analysis I found that the compile phase passes while the linking phase is what crashes it. 

We have the crash dump hosted here.

It is really annoying that program can crash compiler... One would expect compiler to tell us whats wrong with the program. So we are left with no options but to randomly remove lines from the program to find whats wrong unless offcourse if Intel can analyze the crash dump to tell us what can we fix. 

I wonder if any one has faced similar issues ? And what could we a way out. 

Thanks in advance.





0 Kudos
1 Reply

Hello AkhilK,

Thanks for the sighting. I've provided an initial filing internally.

Errors with compilers such as you have described are going to be opaque and should be reported to the vendor. If you have nonproprietary representative reproducers those are useful to provide as well.

For reference for other Intel people reviewing the post... here is my internal filing record: CORC-2897.



0 Kudos