Eigen not working on hipSYCL sample code

I have tried to run a very simple SYCL code that uses EIgen, but fails to compile with cuda backend.
Code is the following:
#include <Eigen/Core>

int main() {
  Eigen::Vector4d a = Eigen::Vector4d::Random();
  Eigen::Vector4d b = Eigen::Vector4d::Random();
  Eigen::Vector4d c = Eigen::Vector4d::Random();

  cl::sycl::default_selector deviceSelector;
  cl::sycl::queue queue(deviceSelector);
  {
    cl::sycl::buffer<Eigen::Vector4d, 1> a_sycl(&a, cl::sycl::range<1>(1));
    cl::sycl::buffer<Eigen::Vector4d, 1> b_sycl(&b, cl::sycl::range<1>(1));
    cl::sycl::buffer<Eigen::Vector4d, 1> c_sycl(&c, cl::sycl::range<1>(1));

    queue.submit([&](cl::sycl::handler& cgh) {
      auto a_acc = a_sycl.get_access<cl::sycl::access::mode::read>(cgh);
      auto b_acc = b_sycl.get_access<cl::sycl::access::mode::read>(cgh);
      auto c_acc =
          c_sycl.get_access<cl::sycl::access::mode::discard_write>(cgh);

      cgh.single_task<class vector_addition>(
          [=]() {});  // c_acc[0] = a_acc[0] + b_acc[0]; });
    });

    // sycl buffers go out of scope and content is copied to host data
    // Are they copied also for a and b which havent changed?
  }

  std::cout << "  A { " << a.x() << ", " << a.y() << ", " << a.z() << ", "
            << a.w() << " }\n"
            << "+ B { " << b.x() << ", " << b.y() << ", " << b.z() << ", "
            << b.w() << " }\n"
            << "------------------\n"
            << "= C { " << c.x() << ", " << c.y() << ", " << c.z() << ", "
            << c.w() << " }" << std::endl;

  return 0;
}

and it fails with the following compilation errors
In file included from ../main.cpp:2:
In file included from /home/jjcasmar/D/usr/local/include/eigen3/Eigen/Core:155:
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/util/Meta.h:263:12: error: no matching function for call to '__int_as_float'
    return CUDART_MAX_NORMAL_F;
           ^~~~~~~~~~~~~~~~~~~
/opt/cuda/include/math_constants.h:57:33: note: expanded from macro 'CUDART_MAX_NORMAL_F'
#define CUDART_MAX_NORMAL_F     __int_as_float(0x7f7fffff)
                                ^~~~~~~~~~~~~~
/usr/lib/clang/10.0.1/include/__clang_cuda_device_functions.h:453:18: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ float __int_as_float(int __a) { return __nv_int_as_float(__a); }
                 ^
In file included from ../main.cpp:2:
In file included from /home/jjcasmar/D/usr/local/include/eigen3/Eigen/Core:155:
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/util/Meta.h:273:12: error: no matching function for call to '__int_as_float'
    return CUDART_INF_F;
           ^~~~~~~~~~~~
/opt/cuda/include/math_constants.h:54:33: note: expanded from macro 'CUDART_INF_F'
#define CUDART_INF_F            __int_as_float(0x7f800000)
                                ^~~~~~~~~~~~~~
/usr/lib/clang/10.0.1/include/__clang_cuda_device_functions.h:453:18: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ float __int_as_float(int __a) { return __nv_int_as_float(__a); }
                 ^
In file included from ../main.cpp:2:
In file included from /home/jjcasmar/D/usr/local/include/eigen3/Eigen/Core:155:
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/util/Meta.h:281:12: error: no matching function for call to '__int_as_float'
    return CUDART_NAN_F;
           ^~~~~~~~~~~~
/opt/cuda/include/math_constants.h:55:33: note: expanded from macro 'CUDART_NAN_F'
#define CUDART_NAN_F            __int_as_float(0x7fffffff)
                                ^~~~~~~~~~~~~~
/usr/lib/clang/10.0.1/include/__clang_cuda_device_functions.h:453:18: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ float __int_as_float(int __a) { return __nv_int_as_float(__a); }
                 ^
In file included from ../main.cpp:2:
In file included from /home/jjcasmar/D/usr/local/include/eigen3/Eigen/Core:155:
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/util/Meta.h:298:12: error: no matching function for call to '__longlong_as_double'
    return CUDART_INF;
           ^~~~~~~~~~
/opt/cuda/include/math_constants.h:91:33: note: expanded from macro 'CUDART_INF'
#define CUDART_INF              __longlong_as_double(0x7ff0000000000000ULL)
                                ^~~~~~~~~~~~~~~~~~~~
/usr/lib/clang/10.0.1/include/__clang_cuda_device_functions.h:511:19: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ double __longlong_as_double(long long __a) {
                  ^
In file included from ../main.cpp:2:
In file included from /home/jjcasmar/D/usr/local/include/eigen3/Eigen/Core:155:
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/util/Meta.h:306:12: error: no matching function for call to '__longlong_as_double'
    return CUDART_NAN;
           ^~~~~~~~~~
/opt/cuda/include/math_constants.h:92:33: note: expanded from macro 'CUDART_NAN'
#define CUDART_NAN              __longlong_as_double(0xfff8000000000000ULL)
                                ^~~~~~~~~~~~~~~~~~~~
/usr/lib/clang/10.0.1/include/__clang_cuda_device_functions.h:511:19: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ double __longlong_as_double(long long __a) {
                  ^
In file included from ../main.cpp:2:
In file included from /home/jjcasmar/D/usr/local/include/eigen3/Eigen/Core:164:
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_char' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1052:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_char)   \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:48: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                               ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:48: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                               ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:23: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                      ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_char' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1052:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_char)   \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:58: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                         ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:43: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                          ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_char' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1052:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_char)   \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:68: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                                   ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:63: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                                              ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_short' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1053:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_short)  \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:48: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                               ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:48: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                               ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:23: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                      ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_short' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1053:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_short)  \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:58: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                         ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:43: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                          ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_short' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1053:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_short)  \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:68: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                                   ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:63: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                                              ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_int' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1054:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_int)    \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:48: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                               ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:48: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                               ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:23: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                      ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_int' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1054:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_int)    \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:58: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                         ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:43: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                          ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_int' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1054:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_int)    \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:68: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                                   ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:63: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                                              ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_long' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1055:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_long)
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:48: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                               ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:48: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                               ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:23: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                      ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_long' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1055:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_long)
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:58: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                         ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:43: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                          ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_long' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1072:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY(NAME, FUNC) \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1055:53: note: expanded from macro 'SYCL_SPECIALIZE_SIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_long)
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:68: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                                   ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:63: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                                              ^~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_uchar' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1073:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_UNSIGNED_INTEGER_TYPES_BINARY(NAME, FUNC)
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1062:53: note: expanded from macro 'SYCL_SPECIALIZE_UNSIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_uchar)  \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:48: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                               ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:48: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                               ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:23: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                      ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1110:1: error: no type named 'cl_uchar' in namespace 'cl::sycl'
SYCL_SPECIALIZE_INTEGER_TYPES_BINARY(mini, min)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1073:3: note: expanded from macro 'SYCL_SPECIALIZE_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_UNSIGNED_INTEGER_TYPES_BINARY(NAME, FUNC)
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1062:53: note: expanded from macro 'SYCL_SPECIALIZE_UNSIGNED_INTEGER_TYPES_BINARY'
  SYCL_SPECIALIZE_BINARY_FUNC(NAME, FUNC, cl::sycl::cl_uchar)  \
                                          ~~~~~~~~~~^
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1108:54: note: expanded from macro 'SYCL_SPECIALIZE_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN2_BINARY_FUNC(NAME, FUNC, TYPE, TYPE)
                                                     ^~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1105:58: note: expanded from macro 'SYCL_SPECIALIZE_GEN2_BINARY_FUNC'
  SYCL_SPECIALIZE_GEN1_BINARY_FUNC(NAME, FUNC, RET_TYPE, ARG_TYPE, ARG_TYPE)
                                                         ^~~~~~~~
/home/jjcasmar/D/usr/local/include/eigen3/Eigen/src/Core/MathFunctions.h:1100:43: note: expanded from macro 'SYCL_SPECIALIZE_GEN1_BINARY_FUNC'
  EIGEN_ALWAYS_INLINE RET_TYPE NAME(const ARG_TYPE1& x, const ARG_TYPE2& y) { \
                                          ^~~~~~~~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated when compiling for sm_60.

I can see two different types of errors:

A CUDA issue ( candidate function not viable: call to __device__ function from __host__ function)
Missing sycl::cl_* data types (e.g. cl_uchar, cl_long)

Regarding 1.: So, hipSYCL effectively compiles code using clang CUDA, augmented so additionally understand SYCL constructs. I assume what is happening is that Eigen enables some CUDA stuff because it concludes that it is compiled by a CUDA compiler. This issue could appear because maybe Eigen's CUDA backend was only tested with nvcc and not with clangs CUDA implementation (they speak slightly different CUDA dialects). I would recommend checking if Eigen's CUDA backend can be compiled with clang's CUDA implementation, independently of hipSYCL.
Also, if you are using CUDA-specific functionality in your kernels (or Eigen uses CUDA-specific functionality), please have a look at https://github.com/illuhad/hipSYCL/blob/develop/doc/hip-source-interop.md
Regarding 2.: These OpenCL data types are a relic of the hardcoded OpenCL backend model in old SYCL 1.2.1 and should not be used in generic SYCL programs (please complain to the Eigen developers). Starting with SYCL 2020, they are only available as part of the (optional) OpenCL backend specification. Since hipSYCL doesn't have an OpenCL backend it's not required to expose those types, so it doesn't have them.
The reasoning is that if you don't have an OpenCL backend, it does not make sense to expose OpenCL-specific data types.

Hi Aksel,
thanks you very much for your fast answer.
To my understanding, Eigen supports clang cuda (https://gitlab.com/libeigen/eigen/-/issues/1173), and in my test code, I dont even use eigen types in a kernel (kernel is empty). If Eigen also supports SYCL backend, could it be that is trying somehow to enable both CUDA backend and SYCL backend for Eigen?
I am not sure your workaround is a good idea, since Eigen defines vectors with different padding depending if it detects CUDA compiler or not, so trying to tweak it may open a can of worms.

To my understanding, Eigen supports clang cuda (https://gitlab.com/libeigen/eigen/-/issues/1173), and in my test code, I dont even use eigen types in a kernel (kernel is empty).

Right. If there's no code inside a kernel, then I'm not sure how hipSYCL could trigger those CUDA issues. I would still recommend checking if you can compile a CUDA version of the same code with clang to narrow down the issue. It might be that clang is not as well tested and there's a regression in Eigen, or that it used to work and only newer clang versions cause trouble etc..

If Eigen also supports SYCL backend, could it be that is trying somehow to enable both CUDA backend and SYCL backend for Eigen?

I think this is exactly what is happening. See https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/util/Macros.h
The assumption that code is either SYCL or CUDA is not correct, since a SYCL implementation might sit on top of CUDA, as hipSYCL odes.

I am not sure your workaround is a good idea, since Eigen defines vectors with different padding depending if it detects CUDA compiler or not, so trying to tweak it may open a can of worms.

I would say, our goal should be to have it treat the vector like a SYCL vector and not like a CUDA one, hence my workaround. It seems you can also disable CUDA in Eigen with the macro EIGEN_NO_CUDA, so this might also be worth a try.

I would still recommend checking if you can compile a CUDA version of the same code with clang to narrow down the issue.

Im not sure I understand what you mean here. How can I compile the same SYCL code with clang?

Just for curiosity, when and how does hipSYCL enables CUDACC? I have tested again changing include order and if I include Eigen/Core before CL/sycl.hpp, compiles and works fine.

Im not sure I understand what you mean here. How can I compile the same SYCL code with clang?

Not the same code, but something that is functionally equivalent in CUDA and compile with clang (clang -x cuda --cuda-path=... --cuda-gpu-arch=...  - you can also see the command line that hipSYCL uses to invoke clang CUDA using HIPSYCL_DRYRUN=1 syclcc ... and then adapt it). Include eigen, create some vectors, copy to device, launch empty kernel etc.

Wouldnt the CUDA implementations inside be dispatched anyway, and therefore may crash because alignment may be different (eigen aligns to enable SSE optimizations in CPU and it doesnt for CUDA)

So how would you target both CPU and CUDA simultaneously? Can Eigen do that?
I believe the SYCL backend inside Eigen is activated because hipSYCL defines SYCL_DEVICE_ONLY during the device compilation pass. It seems this macros is also used internally by Eigen, which then partially activates some SYCL stuff... You could also try
#include <CL/sycl.hpp>
#ifdef SYCL_DEVICE_ONLY
#undef SYCL_DEVICE_ONLY
#endif
#include <Eigen/Core>

Just for curiosity, when and how does hipSYCL enables CUDACC? I have tested again changing include order and if I include Eigen/Core before CL/sycl.hpp, compiles and works fine.

I see, SYCL_DEVICE_ONLY is defined inside sycl.hpp. This is increasingly looking like the root cause to me.

So how would you target both CPU and CUDA simultaneously? Can Eigen do that?
Lets say you have a struct with an eigen value. That struct is going to be aligned to ensure the eigen value is at 16byte.

struct S {
    int a; // 8 bytes
     Eigen::Vector4d b; // 32 byte
};

The size of that struct is 48 in CPU, but 40 in GPU, because in CPU is adding 8 padding bytes after a. To target both at the same time, you need to add the padding manually.
The reason im asking how hipSYCL handles compilation of CUDA code is because in Eigen, CUDA code disables SSE optimizations. I guess that hipSYCL compiles in two phases, one with __CUDACC__ on and one off, no? What would happen if I have some Eigen code for host and some eigen code for device? The host code is compiled without the __CUDACC__ macro?

The size of that struct is 48 in CPU, but 40 in GPU, because in CPU is adding 8 padding bytes after a. To target both at the same time, you need to add the padding manually.

Okay. in this case I think you should in principle add the padding manually when using SYCL in general (i.e. not specific to hipSYCL). The reason is that SYCL is built around a model where you can decide at runtime if you want to dispatch your kernels to CPU or some accelerator. A consequence of this is that the data layout must be the same on CPU and device so that data can be passed between them. You can of course hardcode that your kernel will only run a specific device, then you don't need to worry about it.
The same is of course true for other heterogeneous models such as CUDA, where you also need to assume that the data layout is the same when passing arguments to the kernel. But since CUDA kernels cannot also run on the host, it is maybe easier to make the assumption that only the device is available for computation..

The reason im asking how hipSYCL handles compilation of CUDA code is because in Eigen, CUDA code disables SSE optimizations. I guess that hipSYCL compiles in two phases, one with CUDACC on and one off, no? What would happen if I have some Eigen code for host and some eigen code for device? The host code is compiled without the CUDACC macro?

No. hipSYCL just invokes clang -x cuda for compilation, so it's compiled like any other clang CUDA application (hipSYCL just adds a clang plugin into the mix that performs some additional AST transformations to add support for SYCL specifics).
clang compiles CUDA with two passes, a host pass (which can potentially be used by hipSYCL to also compile the kernel for CPU) and a device pass. In both cases __CUDACC__ is defined. This is necessary during the host pass as well to indicate that CUDA specific language extensions are available, for example the <<<>>> kernel launch syntax.
Currently targeting CPU and GPU simultaneously with hipSYCL is still a bit experimental and it's not done by default, so it might be okay for now to let Eigen assume that it is on CUDA.

Then, if __CUDACC__ is defined in both passes, is like if the code is always a .cu file and Eigen would never do SSE optimizations, right? This probably goes a bit out of the scope of the issue, but how is the kernel extracted?  Is there some documentation I can read to see how the SYCL code is converted into CUDA compatible code?

Then, if CUDACC is defined in both passes, is like if the code is always a .cu file and Eigen would never do SSE optimizations, right?

If Eigen disables SSE when __CUDACC__ is defined, yes. I think the assumption behind that (you can either target CUDA or CPU) is very questionable and arguably incorrect...

This probably goes a bit out of the scope of the issue, but how is the kernel extracted? Is there some documentation I can read to see how the SYCL code is converted into CUDA compatible code?

In short: Kernel code is initially parsed as host code. After initial parsing, the hipSYCL clang plugin then find all kernel invocations (parallel_for() etc) and marks all functions used by the kernel lambda/kernel function object as __host__ __device__. clang code generation is re-invoked to emit kernels during the CUDA device compilation pass.
Kernel lambdas are used to instantiate a launcher function similar to
template<class Kernel> __global__ void launch(Kernel k){
  k();
}

The kernel is not physically extracted by hipSYCL itself, it just lets clang's CUDA toolchain do its magic.
Maybe this talk can help: https://www.youtube.com/watch?v=kYrY80J4ZAs
(it describes the situation in early 2020, so some things have changed a bit since then, but the general principles are still the same)

Looking a bit more, it looks like SYCL implementation on Eigen allows to run Eigen computations on SYCL devices (currently only targeting OpenCL), so if for example you are multiplying two matrices, that multiplication is run on an accelerator.
CUDA support in Eigen is for using Eigen types inside CUDA kernels, which is something completely different. According to Codeplay blog (https://www.codeplay.com/portal/blogs/2017/05/22/implementing-opencl-support-for-eigen-using-sycl-and-computecpp.html), there is also a CUDA backend for running Eigen operations on CUDA, but I havent been able to find any information about it.
So yeah, looks like something is wrong around this.

In short: SYCL kernel code is initially parsed as host code. After initial parsing, the hipSYCL clang plugin then find all kernel invocations (parallel_for() etc) and marks all functions used by the kernel lambda/kernel function object as host device

Not sure about the internals, but wouldn't make sense doing the first pass without the the -x cuda so that CUDACC is not defined?

Not sure about the internals, but wouldn't make sense doing the first pass without the the -x cuda so that CUDACC is not defined?

This is something that I have thought about and could be something to explore in the future. The main advantage of such an approach is that you could have independent device passes for multiple backends, which could in principle allow us to target e.g. both AMD and NVIDIA GPUs simultaneously which is not currently possible. However there are downsides as well:

It requires probably significant engineering effort as it would require us to create parts of the toolchain infrastructure (e.g. embedding of device binaries into the host binary) that we don't have yet since we rely on clang to do that automagically;
There are some additional low-level details to consider, for example we also couldn't rely on the CUDA <<<>>> kernel launch syntax anymore and would need to manually put in the code that clang auto-generates when a <<<>>> kernel launch is encountered;
For me hipSYCL's most unique and important feature compared to other SYCL implementations is that it has full interoperability at the source code level with CUDA and HIP, for example you can mix SYCL and CUDA code to create optimized code paths for NVIDIA GPUs. This means you can for example use CUDA template libraries optimized by NVIDIA from hipSYCL. If we don't have the CUDA host pass anymore, this would break this for all CUDA libraries that rely on the host pass, e.g. for kernel launches with the <<<>>> syntax. An example here would be cutlass.

Especially because of the last issue, if this comes I don't think it would replace the current approach - at most it could be an option for the user to choose with its pros and cons.

For me hipSYCL's most unique and important feature compared to other SYCL implementations is that it has full interoperability at the source code level with CUDA and HIP, for example you can mix SYCL and CUDA code to create optimized code paths for NVIDIA GPUs. This means you can for example use CUDA template libraries optimized by NVIDIA from hipSYCL. If we don't have the CUDA host pass anymore, this would break this for all CUDA libraries that rely on the host pass, e.g. libraries launching CUDA kernels with the usual <<<>>> syntax. An example here would be cutlass.

<<<>>> is by definition a CUDA syntax, and therefore something that must be compiled with a cuda compiler, no? If I understand correctly the issue, since clang will see this code in the host pass with no -x cuda, it wont understand the meaning and will fail, no?
From clang documentation, __CUDACC__ is defined when clang is used to compile cuda code (or -x cuda is passed), but __CUDA_ARCH__ is only defined when actually generating device code, so this should allow to detect when Eigen is parsed for host and when is parsed for device code, no?
Actually, just found that in Eigen master branch, some of the issues are solved and it also aligns automatically even when compiling with __CUDACC__.

<<<>>> is by definition a CUDA syntax, and therefore something that must be compiled with a cuda compiler, no? If I understand correctly the issue, since clang will see this code in the host pass with no -x cuda, it wont understand the meaning and will fail, no?

Correct.

From clang documentation, CUDACC is defined when clang is used to compile cuda code (or -x cuda is passed), but CUDA_ARCH is only defined when actually generating device code, so this should allow to detect when Eigen is parsed for host and when is parsed for device code, no?

Yes, it is possible to detect in which compilation pass you are, e.g. using __CUDA_ARCH__. In hipSYCL you can also use SYCL_DEVICE_ONLY which has the same meaning.

Actually, just found that in Eigen master branch, some of the issues are solved and it also aligns automatically even when compiling with CUDACC.

Great news!

I had a similar problem running hipSYCL with CUDA backend together with Eigen.
And I confirm that

#include <CL/sycl.hpp>
#ifdef SYCL_DEVICE_ONLY
#undef SYCL_DEVICE_ONLY
#endif
#include <Eigen/Core>

worked for me.
btw, I'm using Eigen 3.3.9.


Adds config option to require interface selection before displaying firewall rules.

The default behaviour of firewall_rules.php is to load all firewall rules on the WAN interface if no interface has been previously selected. When a large number of WAN side port forwards/firewall rules, etc exist, loading these rules can put a lot of load on the firewall. On a sufficiently loaded firewall this can actually impact packet forwarding, sometimes leading to packet loss.
This pull request adds an option to require interface selection before loading the firewall rules table, similar to the feature requiring a filter to be in place before populating the state table in diag_dump_states.php (https://github.com/pfsense/pfsense/commit/88081ea257fa683ed28b588c4c35260589604741).

To effectively track changes and bug/feature requests, we require an entry on the pfSense Redmine issue tracker associated with every pull request, and likewise the Redmine entry should also have a link back to the pull request.
Please associate this PR to a Redmine issue either by locating an existing issue at https://redmine.pfsense.org or by creating a new issue. Add a link to the Redmine issue that points to this PR, and also add a link on the PR to the Redmine issue.
For more information, see https://docs.netgate.com/pfsense/en/latest/development/pull-request.html
Thanks!

Redmine entry created. https://redmine.pfsense.org/issues/13124

Due to conflicts I merged this in manually and made a few adjustments along the way, thanks!


I discover new reliable alternative to ffmpeg online

Hello, I have already spoken and posted an issue talking about my discoveries of online tools like yt-dlp online that can help the extension to download or solve some bugs with some rare specific complex videos, and now I notice that this site ::
https://m3u8.dev/
https://m3u8play.dev/
has a powerful online service to gather and download m3u8, mpd streams.....
this site had also extensions to detect and download m3u8, mpd, hls streams.....but recently, chrome store banned this extension and I sent an email to the developer who explained to me that his extensions have suffered a dmca complaint from the rights holders....and that he is currently on vacation and that he plans to add an independent crx version.....
so this is a suggestion and maybe it is good idea to add an option a link to this site or sometimes send the streams and small hls m3u8 fragments to an external online service like https://m3u8.dev/ could solve some transcod problems and bugs if ffmpeg online used by Cat-catch extension don't work :
(it seems there is sometimes some connectivity problems with ffmeg online outsode China) :
https://ffmpeg.bmmmd.com/
Thanks a lot!

Just yesterday, N_m3u8DL-RE received an update :
https://www.videohelp.com/software/N-m3u8DL-RE/version-history


Trim the number of logging instructions

Running TensorFlow + Keras training on Fashion-MNIST shows the following logging statements:
Epoch 1/40
2019-04-16 20:15:01.033264: I tensorflow/core/platform/s3/aws_logging.cc:54] Found secret key
2019-04-16 20:15:01.033390: I tensorflow/core/platform/s3/aws_logging.cc:54] Connection has been released. Continuing.
2019-04-16 20:15:01.077391: I tensorflow/core/platform/s3/aws_logging.cc:54] Found secret key
2019-04-16 20:15:01.077490: I tensorflow/core/platform/s3/aws_logging.cc:54] Connection has been released. Continuing.
2019-04-16 20:15:01.083669: I tensorflow/core/platform/s3/aws_logging.cc:54] Found secret key
2019-04-16 20:15:01.083754: I tensorflow/core/platform/s3/aws_logging.cc:54] Connection has been released. Continuing.

Here is the command to create the pod:
kubectl create -f samples/mnist/training/tensorflow/mnist_train.yaml

This can be trimmed in TensorFlow setup.
@Jeffwan will look at this

We could set proper tensorflow logs level to trim logs. I will file a PR to add to environment


Request: change directional buttons

I think this layout would be the most intuitive and functional!
Left: Left Click
Right: Right Click
Center: Middle Click
Up: Scroll Up
Down: Scroll Down
Back: Return to Menu

This makes little sense without also rotating the coordinate system so that you're pointing towards the screen with the add-on module. I find it a lot more comfortable to hold it like a remote, with the USB port pointing the screen, and in that orientation it's more intuitive to use the current layout.

Ahh, you're right! I forgot to account for the rotation of the device. That orientation makes much more sense.
My new proposed button use:
Left: Scroll Down
Right: Scroll Up
Center: Middle Click
Up: Left Click
Down: Right Click
Back: Return to Menu
I'll update the PR! (And compile+test once my add-on arrives!)

PR #3 now includes this revised button layout!

Sorry, I'm a bit slow, mostly because 'tis the season, I'll definitely test the PR soon.

Anyway, should be all good now, merged and adjusted for better usability. :)