We're probably linking the wrong deviceRTL on HPC systems

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’?