[SYCL] Cannot compile some standard library functions in SYCL mode

[Ruyk]

The following (silly) code:

#include <iostream>
#include <vector>
#include <algorithm>

int main () {
  std::vector<int> foo;

  foo.emplace_back(33);

  std::for_each(std::begin(foo), std::end(foo), [&](int& elem) {
      std::cout << elem << std::endl;
  });

  return foo.size();
};

Fails to compile in SYCL mode:

$ intel_sycl -std=c++11 -fsycl  k.cpp  -lOpenCL -lsycl
In file included from k.cpp:3:
/home/ruyman/Projects/sycl/build/lib/clang/8.0.0/include/sycl_wrappers/algorithm:26:10: error: 
      function 'std::for_each<__gnu_cxx::__normal_iterator<int *, std::vector<int,
      std::allocator<int> > >, (lambda at k.cpp:10:49)>' is used but not defined in this
      translation unit, and cannot be defined in any other translation unit because its type does
      not have linkage
Function for_each(InputIterator first, InputIterator last, Function f);
         ^
k.cpp:10:8: note: used here
  std::for_each(std::begin(foo), std::end(foo), [&](int& elem) {
       ^
1 error generated.
In file included from k.cpp:3:
/home/ruyman/Projects/sycl/build/lib/clang/8.0.0/include/sycl_wrappers/algorithm:26:10: error: 
      function 'std::for_each<__gnu_cxx::__normal_iterator<int *, std::vector<int,
      std::allocator<int> > >, (lambda at k.cpp:10:49)>' is used but not defined in this
      translation unit, and cannot be defined in any other translation unit because its type does
      not have linkage
Function for_each(InputIterator first, InputIterator last, Function f);
         ^
k.cpp:10:8: note: used here
  std::for_each(std::begin(foo), std::end(foo), [&](int& elem) {
       ^
1 error generated.

but works without SYCL on the command line:

$ intel_sycl -std=c++11  k.cpp  -lOpenCL -lsycl
$ 

Is this expected?
Am I correct in understanding that the SYCL mode requires different C++ headers, and that some alias are missing?
Is there any particular reason the normal system headers cannot be used? Note there is no SYCL code in that example.

[bader]

Hi @Ruyk.

Thanks for the reporting this issue.

Is this expected?

No. It's a bug.

Am I correct in understanding that the SYCL mode requires different C++ headers, and that some alias are missing?
Is there any particular reason the normal system headers cannot be used? Note there is no SYCL code in that example.

Even though, this code doesn't have SYCL device functions, the compiler driver always invokes SYCL device compiler. Device compiler compiles for SPIR target and IIRC the compiler can't parse STL headers installed with libstdc++ as they are configured for x86 target and uses specific x86 built-ins/intrinsic functions.
Currently we solved this problem by including "stub" headers for the STL header SYCL device compiler can't parse. It looks like this solution is not robust as it might be broken for different libstdc++ versions and C++ standard version enabled by the compiler.
We will see if we can handle this problem other way to avoid this kind of problems.

[Ruyk]

That makes sense. Stubs are quite difficult to maintain in the long term, specially when you start dealing with different variants and versions of C++ headers.

[keryell]

For this reason in triSYCL we are using the Linux x86 triplet and we "just" override it inside LLVM.
Do you really ended up with x86 intrinsics in the SYCL kernel device code?
I guess that OpenMP/CUDA/Hip solved this somehow...

[bader]

Do you really ended up with x86 intrinsics in the SYCL kernel device code?

You can see the problem by removing/renaming the stubs and trying to compile following program:

#include <algorithm>
#include <random>

[bader]

For this reason in triSYCL we are using the Linux x86 triplet and we "just" override it inside LLVM.

Interesting... how triSYCL compiler implements device code diagnostics from 6.3 section?

[keryell]

Technically we do not yet :-) since our prototype is using late outlining in LLVM and almost no work has been done in Clang yet...
But we have a few things that just use if the SYCL option is passed to the compiler, instead of checking for the triplet... It was too hard to get the standard libraries to compiler otherwise...

[Ruyk]

When working with large C++codebases, its almost inevitable to pull in intrinsics, not only from system libraries, but from optimized headers that have some custom operations or implementations (e.g. SSE implementations of algorithms). Single-source compilation should support this to avoid users forced to rely on pre-processor guards everywhere.
We use the host triple as well in compute++, any x86-intrinsic can be parsed, but an error is raised if this ends up being used on the generated device code.

[bader]

I'd like to bring this discussion to cfe-dev mailing list to see how this is resolved for CUDA/OpenMP.
I'm have doubts that enabling host triple for the device compilation is the right approach.

[josiahls]

Hi, Is there any progress on this? I am trying to run the forEach method calls in opencv and they are failing. I am doing nested for loops right now to iterate through cv::Mat's because of this...

[bader]

Hi, sorry for the delay. We will investigate this problem in next few weeks.
As a workaround I suggest using "__SYCL_DEVICE_ONLY__" macro to disable compilation of STL code on the host by SYCL device compiler.

[keryell]

@josiahls is your code open-source so we can try and look at the alternative?