[Openmp-commits] [PATCH] D94745: [OpenMP][deviceRTLs] Build the deviceRTLs with OpenMP instead of target dependent language

Joachim Protze via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Wed Feb 3 09:56:46 PST 2021

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
> 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.

  rG LLVM Github Monorepo



More information about the Openmp-commits mailing list