-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CUDA back-end fails with OpenCL header problems #2617
Comments
I can't reproduce this problem. Here is what I do: export CUDADIR=/usr/local/cuda-10.1
export PATH=$PATH:$CUDADIR/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CUDADIR/lib64
git clone https://github.com/intel/llvm -b sycl
cd llvm/
python3 ./buildbot/configure.py --cuda
python3 ./buildbot/compile.py
vim /tmp/test.cpp # add reproducer source
./build/install/bin/clang++ -O3 -std=c++17 -ferror-limit=3 -fsycl -fsycl-unnamed-lambda -fsycl-targets=nvptx64-nvidia-cuda-sycldevice /tmp/test.cpp -o /tmp/test.o |
@jeffhammond, were you able to compile the reproducer using these instructions?
|
Clean build from the latest git and it's still broken. I am using the buildbot recipe just like you.
|
What I don't understand is why there is any reference to cl_ext_intel.h when I build for CUDA. Why does the compiler need to know anything about Intel OpenCL to do a non-OpenCL CUDA build? |
Look at this: |
CMake downloads recent version of OpenCL headers and OpenCL ICD loader from Khronos GitHub. These are good for building DPC++ toolchain, but when compiler is invoked, system paths are searched first and if system doesn't have OpenCL headers installed into system other than the version coming with CUDA SDK, there will be conflict. The solution is described in Get Started Guide document - https://intel.github.io/llvm-docs/GetStartedGuide.html#using-the-dpc-toolchain-on-cuda-platforms.
|
I think it might be related to this issue: #1265. |
Yeah, it would be good to have no dependency on OpenCL headers -- especially Intel OpenCL extensions -- in the CUDA back-end. |
I built clang++ like you did and I’m not seeing the problem. Somehow you are getting a bad CL/cl.h .
You should be getting the one in the runtime directory in llvm build, which I am:
# 22 "/localdisk/lfmeadow/llvm/build/install/bin/../include/sycl/CL/cl.h" 2 3
Can you run this on the broken build:
llvm/build/install/bin/clang++ -O3 -std=c++17 -ferror-limit=3 -fsycl -fsycl-unnamed-lambda -fsycl-targets=nvptx64-nvidia-cuda-sycldevice -E saxpy.cc > saxpy.i
and also:
llvm/build/install/bin/clang++ -v -O3 -std=c++17 -ferror-limit=3 -fsycl -fsycl-unnamed-lambda -fsycl-targets=nvptx64-nvidia-cuda-sycldevice saxpy.cc >& log
And send me the two output files. The log will give the include paths and the .i file will show the include files as resolved.
From: Jeff Hammond <notifications@github.com>
Date: Friday, October 16, 2020 at 9:21 AM
To: intel/llvm <llvm@noreply.github.com>
Cc: Meadows, Lawrence F <lawrence.f.meadows@intel.com>, Comment <comment@noreply.github.com>
Subject: Re: [intel/llvm] CUDA back-end fails with OpenCL header problems (#2617)
Yeah, it would be good to have no dependency on OpenCL headers -- especially Intel OpenCL extensions -- in the CUDA back-end.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2617 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABH5YK73BVCGWUE36THLPF3SLBXINANCNFSM4SJFUY5A>.
|
It's picking up /swtools/cuda/latest/include/CL/cl.h all over the place, which is not surprising given I am building for CUDA. |
So am I though. It is the order of the -I that is the problem.
From: Jeff Hammond <notifications@github.com>
Date: Friday, October 16, 2020 at 10:41 AM
To: intel/llvm <llvm@noreply.github.com>
Cc: Meadows, Lawrence F <lawrence.f.meadows@intel.com>, Comment <comment@noreply.github.com>
Subject: Re: [intel/llvm] CUDA back-end fails with OpenCL header problems (#2617)
It's picking up /swtools/cuda/latest/include/CL/cl.h all over the place, which is not surprising given I am building for CUDA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2617 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABH5YK4AMEDXVA4DF33ESFDSLCAT5ANCNFSM4SJFUY5A>.
|
Okay. But you agree that users should not have deal with this, right? DPC++ should download the OpenCL headers it needs and use those first. |
DPC++ already contains the right files, you are picking up the wrong ones.
<tl;dr>
Something is really screwed up about your build. Part of it is that you are getting the wrong gcc, you are getting the ancient 4.8.5:
…-internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5
The only way I could fix that was by adding an argument to clang:
--gcc-toolchain=/opt/intel/gcc7.3
The proximate cause though is a bunch of -I that are somehow getting added (You have some environment variable I expect, something containing the string INCLUDE):
-internal-isystem /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl
-I/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include
-I/swtools/intel/compilers_and_libraries_2017.4.196/linux/ipp/include
-I/swtools/intel/compilers_and_libraries_2017.4.196/linux/mkl/include
-I/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include
-I/swtools/intel/compilers_and_libraries_2017.4.196/linux/daal/include
-I/swtools/cuda/latest/include
-I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/ipp/include
-I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/mkl/include
-I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/pstl/include
-I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include
-I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include
-I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/daal/include
-I/swtools/ninja/latest/include
-I.
You’ve got some pollution from (2 versions of) icc, but the real problem is that this:
-I/swtools/cuda/latest/include
contains CL/cl.h
Mind you so does this:
-internal-isystem /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl
and it comes first so you’d think that clang would find it. -I paths are searched before -internal-isystem paths. From clang -cc1 --help:
-internal-isystem <directory>
Add directory to the internal system include search path; these are assumed to not be user-provided and are used to model system and standard headers' paths.
-I <dir> Add directory to include search path. If there are multiple -I options, these directories are searched in the order they are given before the standard system directories are searched. If the same directory is in the SYSTEM include search paths, for example if also specified with -isystem, the -I option will be ignored
So in summary look for some environment variable probably contain the string INCLUDE and unset it, and provide the right path to --gcc-toolchain, and you should compile.
It runs as long as you set the plugin type:
(py3) [lfmeadow@ortce-skl5 lfmeadow]$ SYCL_DEVICE_FILTER=PI_CUDA ./saxpy.x 4096
SAXPY with 4096 elements
Program completed without error.
From: Jeff Hammond <notifications@github.com>
Date: Friday, October 16, 2020 at 10:45 AM
To: intel/llvm <llvm@noreply.github.com>
Cc: Meadows, Lawrence F <lawrence.f.meadows@intel.com>, Comment <comment@noreply.github.com>
Subject: Re: [intel/llvm] CUDA back-end fails with OpenCL header problems (#2617)
Okay. But you agree that users should not have deal with this, right? DPC++ should download the OpenCL headers it needs and use those first.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2617 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABH5YK2ZVPNBOBZ536Q7UCLSLCBC7ANCNFSM4SJFUY5A>.
|
I've rebuilt DPC++ another 5 times and still cannot get it to pick up the right headers. Whether or not this is solvable, I reject any suggestion that this is something reasonable users are supposed to deal with. I use GCC 10.2 but it still gets the GCC 4.8 headers, presumably because Linux 3.10 and RHEL/CentOS forces this nonsense on this system.
|
You don’t need to rebuild anything. You need to use --gcc-toolchain and point to gcc 10.2 or whatever, and you need to figure out why your environment is inserting all those -I directories. The first -internal-isystem flag points to the directory where CL/cl.h should be found, but then the following -I/swtools/cuda/latest/include is coming from your environment and -I overrides -internal-isystem and the CL/cl.h included with cuda is version 1.x.
env | grep INCLUDE
I’d look for any variable with the string INCLUDE, for example:
GCC_INCLUDE_DIR
CPATH
CPLUS_INCLUDE_PATH
From: Jeff Hammond <notifications@github.com>
Date: Friday, October 16, 2020 at 2:03 PM
To: intel/llvm <llvm@noreply.github.com>
Cc: Meadows, Lawrence F <lawrence.f.meadows@intel.com>, Comment <comment@noreply.github.com>
Subject: Re: [intel/llvm] CUDA back-end fails with OpenCL header problems (#2617)
I've rebuilt DPC++ another 5 times and still cannot get it to pick up the right headers. Whether or not this is solvable, I reject any suggestion that this is something reasonable users are supposed to deal with.
I use GCC 10.2 but it still gets the GCC 4.8 headers, presumably because Linux 3.10 and RHEL/CentOS forces this nonsense on this system.
[jrhammon@pcl-tiergarten dpcpp-tutorial]$ /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/clang++ -v -O3 -std=c++17 -ferror-limit=3 -fsycl -fsycl-unnamed-lambda -fsycl-targets=nvptx64-nvidia-cuda-sycldevice -L/nfs_home/jrhammon/ISYCL/llvm/build/install/lib -Wl,-rpath=/nfs_home/jrhammon/ISYCL/llvm/build/install/lib saxpy.cc
clang version 12.0.0 (/nfs_home/jrhammon/ISYCL/llvm/clang 8c667b6)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nfs_home/jrhammon/ISYCL/llvm/build/install/bin
Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Found CUDA installation: /data/swtools/cuda/cuda-10.2, version 10.2
clang-12: warning: Unknown CUDA version 10.2. Assuming the latest supported version 10.1 [-Wunknown-cuda-version]
"/data/nfs_home/jrhammon/ISYCL/llvm/build/install/bin/clang-12" -cc1 -triple nvptx64-nvidia-cuda-sycldevice -fsycl -fsycl-is-device -fdeclare-spirv-builtins -aux-triple x86_64-unknown-linux-gnu -Wno-sycl-strict -sycl-std=2020 -emit-llvm-bc -emit-llvm-uselists -disable-free -main-file-name saxpy.cc -mrelocation-model static -mframe-pointer=all -fno-rounding-math -fno-verbose-asm -no-integrated-as -aux-target-cpu x86-64 -internal-isystem /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl -mlink-builtin-bitcode /data/nfs_home/jrhammon/ISYCL/llvm/build/install/lib/clang/12.0.0/../../clc/libspirv-nvptx64--nvidiacl.bc -mlink-builtin-bitcode /data/swtools/cuda/cuda-10.2/nvvm/libdevice/libdevice.10.bc -target-feature +ptx65 -target-sdk-version=10.2 -target-cpu sm_50 -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /data/nfs_home/jrhammon/ISYCL/llvm/build/install/lib/clang/12.0.0 -internal-isystem /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl -I/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include -I/swtools/intel/compilers_and_libraries_2017.4.196/linux/ipp/include -I/swtools/intel/compilers_and_libraries_2017.4.196/linux/mkl/include -I/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include -I/swtools/intel/compilers_and_libraries_2017.4.196/linux/daal/include -I/swtools/cuda/latest/include -I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/ipp/include -I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/pstl/include -I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include -I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include -I/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/daal/include -I/swtools/ninja/latest/include -I. -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5 -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5 -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward -internal-isystem /usr/local/include -internal-isystem /data/nfs_home/jrhammon/ISYCL/llvm/build/install/lib/clang/12.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -internal-isystem /usr/local/include -internal-isystem /data/nfs_home/jrhammon/ISYCL/llvm/build/install/lib/clang/12.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -std=c++17 -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir /nfs_home/jrhammon/dpcpp-tutorial -ferror-limit 3 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -fsycl-unnamed-lambda -o /tmp/saxpy-6fb862.bc -x c++ saxpy.cc
clang -cc1 version 12.0.0 based upon LLVM 12.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/swtools/ninja/latest/include"
ignoring nonexistent directory "/include"
ignoring nonexistent directory "/include"
ignoring duplicate directory "/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include"
ignoring duplicate directory "/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include"
ignoring duplicate directory "/nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl"
ignoring duplicate directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5"
ignoring duplicate directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux"
ignoring duplicate directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/data/nfs_home/jrhammon/ISYCL/llvm/build/install/lib/clang/12.0.0/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include
/swtools/intel/compilers_and_libraries_2017.4.196/linux/ipp/include
/swtools/intel/compilers_and_libraries_2017.4.196/linux/mkl/include
/swtools/intel/compilers_and_libraries_2017.4.196/linux/daal/include
/swtools/cuda/latest/include
/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/ipp/include
/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/mkl/include
/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/pstl/include
/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include
/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/daal/include
.
/nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward
/usr/local/include
/data/nfs_home/jrhammon/ISYCL/llvm/build/install/lib/clang/12.0.0/include
/usr/include
End of search list.
In file included from saxpy.cc:1:
In file included from ./tutorial.hpp:6:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl.hpp:11:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/ONEAPI/atomic.hpp:11:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/ONEAPI/atomic_accessor.hpp:11:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/ONEAPI/atomic_enums.hpp:12:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/access/access.hpp:10:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/detail/common.hpp:11:
/nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/cl_ext_intel.h:431:9: error: unknown type name 'cl_properties'
typedef cl_properties cl_mem_properties_intel;
^
In file included from saxpy.cc:1:
In file included from ./tutorial.hpp:6:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl.hpp:11:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/ONEAPI/atomic.hpp:11:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/ONEAPI/atomic_accessor.hpp:11:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/ONEAPI/atomic_enums.hpp:12:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/access/access.hpp:10:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/detail/common.hpp:121:
In file included from /nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/exception.hpp:15:
/nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/detail/pi.h:228:7: error: use of undeclared identifier 'CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES'
CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES,
^
/nfs_home/jrhammon/ISYCL/llvm/build/install/bin/../include/sycl/CL/sycl/detail/pi.h:229:45: error: use of undeclared identifier 'CL_DEVICE_QUEUE_ON_HOST_PROPERTIES'
PI_DEVICE_INFO_QUEUE_ON_HOST_PROPERTIES = CL_DEVICE_QUEUE_ON_HOST_PROPERTIES,
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
4 errors generated.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2617 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABH5YK6JQVPKAQQ4SEY24UDSLCYGLANCNFSM4SJFUY5A>.
|
It was
|
The resulting binary doesn't work, but I'm just done with this machine.
|
That one is insidious. I see that I have it set as well because of oneapi scripts. I really don’t like the way we burden the environment for everything. I don’t know if I have a better solution.
From: Jeff Hammond <notifications@github.com>
Date: Friday, October 16, 2020 at 2:33 PM
To: intel/llvm <llvm@noreply.github.com>
Cc: Meadows, Lawrence F <lawrence.f.meadows@intel.com>, Comment <comment@noreply.github.com>
Subject: Re: [intel/llvm] CUDA back-end fails with OpenCL header problems (#2617)
It was CPATH, which contained /swtools/cuda/latest/include.
$ echo $CPATH
/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include:/swtools/intel/compilers_and_libraries_2017.4.196/linux/ipp/include:/swtools/intel/compilers_and_libraries_2017.4.196/linux/mkl/include:/swtools/intel/compilers_and_libraries_2017.4.196/linux/tbb/include:/swtools/intel/compilers_and_libraries_2017.4.196/linux/daal/include:/swtools/cuda/latest/include:/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/ipp/include:/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/mkl/include:/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/pstl/include:/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include:/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/tbb/include:/data/swtools/intel/compilers_and_libraries_2019.3.199/linux/daal/include:/swtools/ninja/latest/include:
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2617 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABH5YKZND77YFPXXBHUS74LSLC3ZZANCNFSM4SJFUY5A>.
|
In fairness to At least now there is a record of my suffering for future internet readers to learn from. |
Hi! OneDNN library also encountered with the same issue. It's hard to blame CMake that it can't find proper headers automatically since FindOpenCL.cmake (the latest its version) searches for CL/cl.h or OpenCL/cl.h, which is the regular way OpenCL is distributed. DPC++ compiler decision was to encapsulate CL/cl.h into a sycl subfolder: compiler/include/sycl/CL/cl.h. This subdirectory actually messes things up for CMake. The work around we applied on our side is creating ~CL symlink in include folder to sycl/CL. This way CMake internals are not needed to be modified. Probably, the proper way to deal with it is to teach CMake work with OpenCL headers in case of DPC++ compiler. But this requires someone to contribute into CMake... |
I am using 69825ee:
I build like this:
The tool fails like this:
This is the source code:
The text was updated successfully, but these errors were encountered: