Use of SYCL builtin name causes odd compilation failure

[JamesR]

I used a function named "dot" in my program (its is actually a function from the "Ray Tracing in a Weekend" online course... all free, and widely available and well used - so it is a real world example of code!).

It turns out that dot is the name of a builtin in the SYCL language.

The runtime crash that this cause is definitely NOT the right answer.  :)

This brings up an interesting list of questions about what is the right answer... and I will leave it to you to consider.  The keys would be - what behavior do you want without "namespace sycl" and with "namespace sycl" in place when a SYCL builtin name is used by a user function.

It would seem to me - it either needs to be legal, and preempt the SYCL function... or it should be flagged as not allowed.  I do NOT know what the SYCL specification would say is the right answer.

Clearly - the DPC++ compiler does neither... hence this bug report.

//
//
// clang++ -fsycl -I common -std=c++20 -o test test.cc -ferror-limit=1  -fsycl-unnamed-lambda  -Wall -Wpedantic
// ./test
// <origin>: error: Invalid record (Producer: 'LLVM9.0.0' Reader: 'LLVM 9.0.0')
// terminate called after throwing an instance of 'cl::sycl::compile_program_error'
//   what():  The program was built for 1 devices
// Build program log for 'Intel(R) Gen9 HD Graphics NEO':
// Parsing llvm module failed! -17 (CL_LINK_PROGRAM_FAILURE)
// Makefile:26: recipe for target 'test' failed
// make: [test] Aborted (ignored)
//
//
// clang++ -fsycl -DWorkAroundCompilerBug -I common -std=c++20 -o testworkaroundapplied test.cc -ferror-limit=1  -fsycl-unnamed-lambda  -Wall -Wpedantic
// ./testworkaroundapplied
// 0.14
//
// clang++ -v
// Intel(R) oneAPI DPC++ Compiler 2021.1-beta06 (2020.4.0.0415)
// Target: x86_64-unknown-linux-gnu
// Thread model: posix
// InstalledDir: /glob/development-tools/versions/oneapi/beta06/inteloneapi/compiler/latest/linux/bin
// Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
// Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
// Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
// Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
// Candidate multilib: .;@m64
// Selected multilib: .;@m64
//

#include <CL/sycl.hpp>
using namespace sycl;

#include <iostream>

class vec3 {
    public:
        vec3(double e0, double e1, double e2) : e{e0, e1, e2} {}
    public:
        double e[3];
};

#ifdef WorkAroundCompilerBug
#define dot(A,B) mydot(A,B)
#endif

// inline or no inline - does not seem to matter
inline double dot(const vec3 &u, const vec3 &v) {
    return u.e[0] * v.e[0] + u.e[1] * v.e[1] + u.e[2] * v.e[2];
}

int main() {
    auto my_device_q = queue(gpu_selector{});
    const unsigned size = 1;
    range<1> fbSize{ (unsigned long)size };
    
    double *result = (double *)malloc_shared(sizeof(double)*size,my_device_q);
    for (int i=0;i<size;)result[i++]=42.42;
    my_device_q.parallel_for(fbSize,[=](id<1> idx) { result[0] = dot(vec3(0.0,0.1+idx,0.2),vec3(0.3,0.4,0.5+idx)); } ).wait();

    std::cout << result[0] << std::endl;
}

- james

[GouthamK_Intel]

Hi James,

Thanks for reporting the bug.!

We are able to reproduce the run time error which you are facing. 

We are escalating this to the concerned team.

Have a Good day!

Thanks & Regards,

Goutham

[Anoop_M_Intel]

This error only pops up when we select OpenCL backend. With Level0 backend, I don't see the same problem as shown below:

$ dpcpp test.cc
$ ./a.out
9.84324e-317

$ export SYCL_BE=PI_OPENCL
$ ./a.out
<origin>: error: Invalid record (Producer: 'LLVM9.0.0' Reader: 'LLVM 9.0.0')
terminate called after throwing an instance of 'cl::sycl::compile_program_error'
  what():  The program was built for 1 devices
Build program log for 'Intel(R) Gen9 HD Graphics NEO':
Parsing llvm module failed! -17 (CL_LINK_PROGRAM_FAILURE)
Aborted (core dumped)

Further investigation of OpenCL spec reveals that there is a dot() builtin function in OpenCL as per the specification documented at https://www.khronos.org/registry/OpenCL/specs/2.2/pdf/OpenCL_C.pdf, section 6.13.5 (Geometric Functions).

[Anoop_M_Intel]

dot() function is a builtin intrinsic function in OpenCL and the compiler was silently expanding it without any typechecking. This issue is already fixed in the product. Please try the latest update of Intel DPC++ Compiler.