OpenCL clBuildProgram intermittent segfault on Intel HD 520 on Ubuntu Linux 19.04

[thenumbernine]

I'm using the latest release of intel opencl icd on Ubuntu Linux 19.04

The following OpenCL code intermittently causes a segfault in clBuildProgram:

#if	1	//double fails
#pragma OPENCL EXTENSION cl_khr_fp64 : enable
typedef double real;
#else	//float seems to work
typedef float real;
#endif

typedef union {
	real s[3];
	//commenting out the other union has no effect on preventing the intermittent crash
	struct { real x, y, z; };
} real3;

real3 real3_zero() {
	//intermittently crashes the compiler
	return (real3){.s={0,0,0}};
	//works 
	//return (real3){.x=0, .y=0, .z=0};
}

kernel void addSource() {
	//produces a crash depending on the body of real3_zero()
	real3 conn12 = real3_zero();
	//works -- produces no compiler crash
	//real3 conn12 = (real3){.s={0,0,0}};
	//works -- produces no compiler crash
	//real3 conn12 = (real3){.x=0, .y=0, .z=0};
}

Using float instead of double seems to prevent the crash.

Changing the initialization of the union from initializing the array 's' to initializing the individual fields 'x', 'y', 'z' seems to prevent the crash.

Directly assigning the union value to the variable in the kernel rather than returning it through a function seems to prevent the crash.

A stack trace from GDB reveals that the crash is coming from the following location:

(gdb) run
Starting program: /home/chris/Projects/cpp/IntelGPUIsolatedBug2/dist/linux/debug/IntelGPUIsolatedBug2 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3f7f700 (LWP 11891)]
[New Thread 0x7ffff116e700 (LWP 11893)]
[Thread 0x7ffff116e700 (LWP 11893) exited]

Thread 1 "IntelGPUIsolate" received signal SIGSEGV, Segmentation fault.
0x00007ffee8e0bd0b in llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) ()
   from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1
(gdb) bt
#0  0x00007ffee8e0bd0b in llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) ()
   from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1
#1  0x00007ffee8e02b09 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1
#2  0x00007ffee8e00268 in llvm::IRBuilderBase::CreateMemSet(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int, bool, llvm::MDNode*, llvm::MDNode*, llvm::MDNode*) ()
   from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1
#3  0x00007ffee6c73858 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#4  0x00007ffee6c73b73 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#5  0x00007ffee6c75c08 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#6  0x00007ffee6c7991f in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#7  0x00007ffee6c7a5a8 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#8  0x00007ffee6bd311a in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#9  0x00007ffee6bd6f45 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#10 0x00007ffee6bd8858 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#11 0x00007ffee6c85917 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#12 0x00007ffee6c882b5 in ?? () from /usr/lib/x86_64-linux-gnu/libigc.so.1
#13 0x00007ffff792401f in ?? () from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#14 0x00007ffff796b6f6 in ?? () from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#15 0x00007ffff78fc956 in ?? () from /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so
#16 0x0000555555555653 in main (argc=1, argv=0x7fffffffd998) at src/main.cpp:77

[paigeale]

Hello Christopher (@thenumbernine),

Our compiler team will take a look at this crash and work to reproduce it locally. Thank you for providing the problem kernel and stack trace dump.

-Alex

[paigeale]

@thenumbernine

It turns out there is a bug in our SPIRVReader when processing the OpCopyMemorySized spirv opcode. The fix is going through our internal testing currently and should be available tomorrow. Thank you for your patience.