[Openmp-dev] We're probably linking the wrong deviceRTL on HPC systems

[Jon Chesterfield via Openmp-dev]

The openmp devicertl is version locked to clang. Roughly, we change clang
and the devicertl at the same time, in ABI and API breaking fashion.

Clang searches for the devicertl to link in CommonArgs.cpp,
tools::addOpenMPDeviceRTL.  That starts,

SmallVector<StringRef, 8> LibraryPaths;
  // Add user defined library paths from LIBRARY_PATH.


  auto LibPath = llvm::sys::Process::GetEnv("LIBRARY_PATH");
  if (LibPath) {
 ...      LibraryPaths.emplace_back(Path.trim());
  }

That is, LIBRARY_PATH gets looked in first. There's no particular guarantee
that LIBRARY_PATH has anything to do with the current compiler, e.g. on a
HPC system it probably points to some other loaded compiler.

User specified wins. That's good. If the user doesn't specify one, first
point in LIBRARY_PATH wins, which isn't especially likely to be the one
that we shipped with clang.

I think that is a severe bug. If the user doesn't specify a library, we
should use the one from clang's lib directory. if there isn't one there, we
should error. Grabbing a bitcode file from somewhere else in the filesystem
has minimal chance of working and I doubt the error symptoms are helpful.

Anyone dead set against me ripping out that 'feature'?

Thanks!

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20210730/e07da416/attachment.html>