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

Reply via email to