jhuber6 wrote:
> Hi @jhuber6, @MaskRay
>
> We are having some problems with this patch on a server where the file
> /lib64/libomptarget-nvptx-sm_52.bc exists. The test case that fails is
> clang/test/Driver/openmp-offload-gpu.c.
>
> **Problem 1** I think one problem is related to this check line `//
> CHK-ENV-BCLIB:
> clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|\\\\}}libomptarget-nvptx-sm_52.bc
> ` That test is using `env LIBRARY_PATH` but your changes in
> `tools::addOpenMPDeviceRTL` makes it prioritize the standard library paths
> before the environment. Not sure if that is how it should be or if env should
> have higher prio (i.e. added to LibraryPaths before the paths found in
> HostTC).
>
> **Problem 2** This check line also started failing: `// CHK-BCLIB-WARN: no
> library 'libomptarget-nvptx-sm_52.bc' found in the default clang lib
> directory or in LIBRARY_PATH; use '--libomptarget-nvptx-bc-path' to specify
> nvptx bitcode library `
>
> Now, with your path, I guess it starts picking up the
> `/lib64/libomptarget-nvptx-sm_52.bc` file from the system. So we no longer
> get the warning. Is that the intention with your patch? Regardless, I think
> you need to do something with that test case because I think the "should
> never exist" part in
>
> ```
> /// Check that the warning is thrown when the libomptarget bitcode library is
> not found.
> /// Libomptarget requires sm_52 or newer so an sm_52 bitcode library should
> never exist.
> ```
>
> no longer holds with your patch.
I think it's standard to prioritize library path stuff. Does this work if you
just flip the order we fill the library search path? I think the behavioral
change here is that we didn't used to look in the system directory.
https://github.com/llvm/llvm-project/pull/83282
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
