Nicolas Miller

@hqhy please note that the earliest version of ROCm that was tested with DPC++ for hip was 4.2, so I'm not sure if it is related to the error here...

I've been looking into this and I'm still trying to track down exactly what the issue is, but I found out that on `gfx906` adding the `-fno-unroll-loops` flag to `SYCL_CXX_FLAGS_EXTRA`...

I wasn't able to test this on ROCm 5.2.1. However I ended up tracking this all the way down to what I believe is a bug in the compiler during...

The patch has now been merged in upstream LLVM, so it should land in DPC++ in the next pulldown.

That's a very interesting question, just a few notes on that: * This patch doesn't add `RPATH` to any binaries that would end up in the DPC++ packages for two...

The main idea of this patch is to make it a bit more user friendly to use the SYCL compiler by removing the need to set `LD_LIBRARY_PATH` to run samples...

> @npmiller, have there been any discussions/concerns raised when -fopenmp-implicit-rpath was added in upstream? I assume we just trying to follow same path here? Here's the upstream discussion when adding...

> The PI plugins are in the same directory as libsycl.so so they also benefit from the `rpath` I just realized this is incorrect, I was just experimenting with a...

Note that with https://github.com/intel/llvm/pull/6658 `libsycl.so` is now able to find the plugin even without `LD_LIBRARY_PATH` set, which solves the issue raised earlier, so now this patch would work better.

> And we're expecting the compiler to build libclang_rt.builtins.a file which we need to link with a library The default target of `compile.py` is `deploy-sycl-toolchain` which I don't think includes...