Seg fault reading const scalar

I’ve come across a segmentation fault with ComputeCpp 1.1.3 with the code below on Ubuntu 19.04 and the Intel CPU driver. Do you see it at your side?

#include <iostream>                                                              
#include <CL/sycl.hpp>                                                           
// segfault on ComputeCpp 1.1.3                                                  
namespace kernels { class K; }                                                   
int main(int argc, char *argv[])                                                 
  using namespace cl::sycl;                                                      
  int data[64];                                                                  
  queue q;                                                                       
  const int w = 3;                                                               
    buffer<int,1> buf(data,range<1>{64});                                        
    q.submit([&](handler &cgh) {                                                 
      auto acc = buf.get_access<access::mode::read_write>(cgh);                  
      auto r = range<3>{4,4,4};                                                  
      cgh.parallel_for<kernels::K>(r, [=](item<3> ix) {                          
        const int offset = w;                                                    
        acc[ix.get_linear_id()] = offset;                                        
  for (const auto i : data) { std::cout << i; }                                  
  std::cout << '\n';                                                             
  return 0;                                                                      

Hi Paul, We haven’t fully tested with 19.04 yet. I’ll see if the details of the segfault gives any clues.

Hi Paul,

I have set up a fresh 19.04 VM with the latest Intel (CPU) drivers (version and ComputeCpp-CE (version 1.1.3), and there were no run-time errors.

Compiled directly with compute++:

/path/to/computecpp-ce-113/bin/compute++ ccpp-segfault.cpp -O3 -mllvm \ 
 -inline-threshold=1000 -sycl-driver -sycl-target spir64 -no-serial-memop \
 -I /path/to/computecpp-ce-113/include -o ccpp-segfault -std=c++11 \ 
 -L /path/to/computecpp-ce-113/lib -lComputeCpp 


333333333 ...

Hi Georgi,

That is very helpful. With that command I also have no error. I was using three separate commands - as shown below - inspired by the CMake scripts in the computecpp-sdk repository:

/path/to/computecpp-ce-113/bin/compute++ -std=c++11 -no-serial-memop -O2 -sycl -emit-llvm -I /path/to/computecpp-ce-113/include -o const_read_segfault.cpp.bc -c const_read_segfault.cpp

g++ -DBUILD_PLATFORM_SPIR -I /path/to/computecpp-ce-113/include -O2 -include const_read_segfault.cpp.sycl -std=c++1z -pthread -o const_read_segfault.cpp.o -c const_read_segfault.cpp

g++ -std=c++1z -pthread const_read_segfault.cpp.o -rdynamic -O2 -L /path/to/computecpp-ce-113/lib/ -lComputeCpp -lOpenCL

I’d noticed that scan.cpp from computecpp-sdk also produces a seg fault. So too, compiling it instead using a single command such as yours, produces an executable which runs with no error.


Hi Paul,

Glad to see that compiling the final binary directly with compute++ works for you!

Regarding scan.cpp from the SDK, I compiled it using our cmake script and have no segfault on both CPU and GPU. I am using the latest driver versions of Intel OpenCL.
I would suggest getting the latest intel compute-runtime (from a week ago - 13th of June) and trying again.

Update: I was about to leave you clueless on whether you could keep using your method of compiling, which actually looks fine to me… Thus, I tried the 3-staged compilation using the provided commands (thanks for sharing them :star:) and seem to be able to produce a binary with no run-time errors for both const_read_segfault and scan example programs. Thus, all I can think of is having a go at drivers update and see what happens after that.


Further information on Intel Drivers:

scan.cpp from our SDK seem to segfault when using Intel’s Experimental OpenCL CPU Runtime with SYCL support (driver version: 2019.8.4.0), assuming the SDK is built using the CMake script in the repository. Compiling it with a single command, as shown above, produces an error-less binary.

I would suggest this being reported to Intel as CPU drivers issue.


Thanks for your help Georgi, I’ll do that.

I note also that using Clang instead of GCC in the 3-stage command produces no error.

By the way, is it possible to select different host compilers using the approach of a single compute++ invocation?


Hey Paul,

Apologies for the late response!

By the way, is it possible to select different host compilers using the approach of a single compute++ invocation?

Unfortunately, it will not be possible because compute++ is the sole compiler used in this approach.

More specifically,
The sycl-driver option makes the compiler assume that the input is a C++11 source file. Therefore, when using the sycl-driver option, the compute++ compiler will produce an object containing host code and device kernels.

Calls to the compiler are scheduled as:

  • first run: with the -sycl flag to extract kernels and emit the integration header.

  • second run: without the -sycl flag and automatically include the integration header.
    On the second run it will act as standard clang (clang++ 6.0) compiler.

If you experience gcc to be producing a faulty binary when used as a host compiler with ComputeCpp and any of the (latest) stable driver releases from Intel, please let me know. As far as I have looked into this, it seems to concern only Intel’s new experimental drivers.