Created attachment 113538 [details]
This simple kernel triggers the described bug.

Trying to compile the attached kernel results in an assertion failure.
This is a stripped down version, and it makes no sense at all, it only includes the minimal amount of code required to still trigger the bug.


The setup process I used was:

- Installed version 3.5.1 of the LLVM toolchain from the official apt repo of llvm.org, the one intended for Ubuntu Trusty.
- Downloaded beignet-1.0.1-src.tar.gz from 01.org, extracted it, and followed the "How to build and install" guide on the freedesktop.org wiki.
- Tried to build the attached kernel.


With Beignet 1.0.1 the error message I get when clBuildProgram is called:

ASSERTION FAILED: vecType->getNumElements() == imm.getElemNum() && getTypeByteSize(unit, vecType->getElementType()) == imm.getTypeSize()
  at file (...)/Beignet-1.0.1-Source/backend/src/llvm/llvm_gen_backend.cpp, function gbe::ir::ImmediateIndex gbe::GenWriter::processConstantImmIndex(llvm::Constant*, int32_t), line 1059
Trace/breakpoint trap


Then I checked out the latest commit, which is 1b3bb70 as of now, the message changed to:

ASSERTION FAILED:  The bit sizes of src and the dst is not identical.
  at file (...)/beignet-git/backend/src/ir/context.cpp, function void gbe::ir::Context::append(const gbe::ir::Instruction&), line 165
Trace/breakpoint trap


The head of the output of utests/utest_run:

platform number 1
platform_profile "FULL_PROFILE"
platform_name "Intel Gen OCL Driver"
platform_vendor "Intel"
platform_version "OpenCL 1.2 beignet 1.0.1"
platform_extensions "cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd"
device_profile "FULL_PROFILE"
device_name "Intel(R) HD Graphics IvyBridge M GT2"
device_vendor "Intel"
device_version "OpenCL 1.2 beignet 1.0.1"
device_extensions "cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd"
device_opencl_c_version "OpenCL C 1.2 beignet 1.0.1"
21 image formats are supported
[CL_R CL_UNORM_INT8]
[CL_R CL_UNORM_INT16]
[CL_R CL_SIGNED_INT8]
[CL_R CL_SIGNED_INT16]
[CL_R CL_SIGNED_INT32]
[CL_R CL_UNSIGNED_INT8]
[CL_R CL_UNSIGNED_INT16]
[CL_R CL_UNSIGNED_INT32]
[CL_R CL_HALF_FLOAT]
[CL_R CL_FLOAT]
[CL_RGBA CL_UNORM_INT8]
[CL_RGBA CL_UNORM_INT16]
[CL_RGBA CL_SIGNED_INT8]
[CL_RGBA CL_SIGNED_INT16]
[CL_RGBA CL_SIGNED_INT32]
[CL_RGBA CL_UNSIGNED_INT8]
[CL_RGBA CL_UNSIGNED_INT16]
[CL_RGBA CL_UNSIGNED_INT32]
[CL_RGBA CL_HALF_FLOAT]
[CL_RGBA CL_FLOAT]
[CL_BGRA CL_UNORM_INT8]


Using the latest commit makes no difference to this output, other than the Beignet version string, of course.

I am pretty new to OpenCL, so it is possible that there is something wrong with the kernel (like using undefined behaviour), but the compiler shouldn't crash, regardless of the input it is given.

If you need any additional information to reproduce the bug, feel free to contact me.