Compiler segfault passing scalar argument to select()

[picomancer]

I have no idea if this forum is the best place to submit bug reports. If I should file this somewhere else, let me know.

Description of the bug

Compiling select(v, 0, s) -- with v and s previously declared and initialized as vectors -- results in a segfault. Casting the zero to the same vector type as v fixes this, i.e. if v is uint16, then select(v, (uint16) 0, s) is ok.

I've attached a minimal kernel that causes the problem to this post, together with shell scripts and GDB backtraces of the problem. The segfault occurs in both PyOpenCL and the ioc64 standalone compiler.

My Environment

Intel OpenCL SDK version: opencl-1.2-3.0.67279

OS: Linux Mint 14, 64-bit

OpenCL ICD: ocl-icd-libopencl1

PyOpenCL: Commit 0b7e385d39460aef7043cf02a5051efa42700a9e from http://git.tiker.net/trees/pyopencl.git

Expected Behavior

Regardless of whether the syntax is legal, IMHO the compiler should never segfault -- a program that doesn't compile, or out-of-memory conditions, should always pass an error code or exception up to the application. (IMHO the syntax should be legal, the compiler should upcast automatically...but reading the spec carefully, this is only specified for operators; function arguments apparently must be cast manually. Which is really dumb on the part of the spec. Maybe there should be a pragma...)

Thoughts on Solution

The backtrace has many frames in clang.  So there is a decent probability this is actually a clang bug.  The solution may be as simple as rebuilding the SDK with the latest upstream version of clang.  In this case, it's really a packaging issue -- that an existing fix for a known bug hasn't worked its way into the SDK download on the Intel website.  Or it may be a clang bug triggered by Intel-specific code that interfaces to or modifies clang.  Or the bug may also be totally unrelated to clang -- e.g. a memory-corruption-causing bug in unrelated code overwriting clang data structures, which cause a crash when clang is eventually triggered and attempts to use the corrupt data structures.

Up-to-date information

I'd like to ask anyone reading this thread to contribute any up-to-date references or further information.  If this is the result of a known upstream bug, or if there's a public discussion of this bug in the clang community or elsewhere, I'd appreciate if someone could post a reference to those resources here.  If this is eventually resolved, it'd be nice to note the version where it's fixed.  If this discussion is moved elsewhere on intel.com, i.e. to a bug-tracker, a reply here with a pointer there would be appreciated.

[Yuri_K_Intel]

Hi, Thank you for reporting this issue. Yes, this is the right place to submit bug reports. I was able to reproduce it on the specified version (opencl-1.2-3.0.67279), but it's no longer reproducible on latest internal version to be released sometime later this year. Meanwhile, please use a workaround. Thanks, Yuri