You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We previously added support for building `libsycl` individually with
`libc++`. At that time, `libsycl` didn't link against `libLLVM` so they
did not need to be using the same STL implementation.
Now, `libsycl` does link against `libLLVM`, one example
[here](https://github.com/intel/llvm/blob/sycl/sycl/source/CMakeLists.txt#L98).
Remove all the code that was to support `libsycl` in particular and just
make it work with the normal option LLVM uses, `LLVM_ENABLE_LIBCXX`.
Most of the code I added actually checks `LLVM_LIBCXX_USED`, because
LLVM checks at configure time if `libc++` actually works even when
passed `LLVM_ENABLE_LIBCXX`, and if it fails, it falls back to
`libstdc++`, and most of the time we actually want to know if we are
actually using `libc++`.
I added a CMake option `SYCL_LIBDEVICE_CXX_FLAGS` to set the flags for
libdevice because it will be required if someone doesn't use the LLVM
option and just does it through `CMAKE_CXX_FLAGS`, as those aren't used
for libdevice but it still uses the STL.
The two changes in
`unified-runtime/source/loader/layers/sanitizer/msan/msan_libdevice.hpp`
and `sycl/source/builtins/common_functions.cpp` fix compile errors with
`libc++`.
I also plan to add a job to the nightly to lock this down.
#19347
---------
Signed-off-by: Sarnie, Nick <[email protected]>
0 commit comments