protze.joachim added a comment. In D94745#2539454 <https://reviews.llvm.org/D94745#2539454>, @JonChesterfield wrote:
> I think there's a bug report about this. Sycl (iirc) introduced a change that > caught invalid things with types that were previously ignored. @jdoerfert is > on point I think. > > `-DLLVM_ENABLE_PROJECTS="clang;compiler-rt;libcxxabi;libcxx;libunwind;openmp" > ` > ^ That works, if the compiler in question can build things like an nvptx > devicertl, which essentially means if it's a (sometimes very) recent clang. A > generally easier path is > `-DLLVM_ENABLE_RUNTIMES="openmp"` > as that will build clang first, then use that clang to build openmp. > > Won't help in this particular instance - if I understand correctly, it's a > misfire from using glibc headers on the nvptx subsystem - though that > stdlib.h looks like it shipped as part of libc++. > > edit: I am too slow... I tried @jdoerfert 's patches, but they are not even necessary to address my building issue. Just delaying the build of OpenMP by setting `-DLLVM_ENABLE_RUNTIMES="openmp"` helped. From my perspective, we should error out if people try to build OpenMP as a project rather than runtime and print a error message about what to change. In any case, a stand-alone build of OpenMP still fails with any of the older clang compilers. Should we disable building of libomptarget, if an old clang is used? CMake diagnostic could suggest to use in-tree build for libomptarget. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94745/new/ https://reviews.llvm.org/D94745 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits