jhuber6 wrote:
> Fixed the issue
> [0fa04b6](https://github.com/llvm/llvm-project/commit/0fa04b6e2cd2169a8e3d22ae879394dbf07c0466)
> Unrelated to building as projects.
Hah, I probably should've noticed that. Explains why I didn't notice because I
always have tests enabled.
ye-luo wrote:
Fixed the issue
https://github.com/llvm/llvm-project/commit/0fa04b6e2cd2169a8e3d22ae879394dbf07c0466
Unrelated to building as projects.
https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
ye-luo wrote:
I'm OK with the first two
```
-DLLVM_RUNTIME_TARGETS=default;amdgcn-amd-amdhsa;nvptx64-nvidia-cuda
Enables the runtimes for the target triples, default is what you get without
specifying anything
```
I actually think default should automatically include amdgcn and nvptx when I
jhuber6 wrote:
> Could you explain what each line does exactly?
This is hypothetical, but it's a potential way to keep it from having a
separate project
`-DLLVM_RUNTIME_TARGETS=default;amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`
Enables the runtimes for the target triples, default is what you get
ye-luo wrote:
Could you explain what each line do exactly?
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
jhuber6 wrote:
> > > @jdoerfert I would like to see the device code compilation (on device
> > > runtime) and host runtime compilation fully separate. Then I can build
> > > the runtime with gcc or sanitizer without disturbing device code
> > > compilation.
> >
> >
> > Could you elaborate
ye-luo wrote:
> > @jdoerfert I would like to see the device code compilation (on device
> > runtime) and host runtime compilation fully separate. Then I can build the
> > runtime with gcc or sanitizer without disturbing device code compilation.
>
> Could you elaborate on this? One of my
jhuber6 wrote:
> @jdoerfert I would like to see the device code compilation (on device
> runtime) and host runtime compilation fully separate. Then I can build the
> runtime with gcc or sanitizer without disturbing device code compilation.
Could you elaborate on this? One of my long-term
ye-luo wrote:
> > @jhuber6 could you build openmp as a project instead of runtime?
>
> Ah, I could try that. Though I believe that Johannes is going to completely
> deprecate the projects build once moving to llvm/offload.
@jdoerfert I would like to see the device code compilation (on device
jhuber6 wrote:
> @jhuber6 could you build openmp as a project instead of runtime?
Ah, I could try that. Though I believe that Johannes is going to completely
deprecate the projects build once moving to llvm/offload.
https://github.com/llvm/llvm-project/pull/83282
ye-luo wrote:
@jhuber6 could you build openmp as a project instead of runtime?
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
ye-luo wrote:
Still a myth on my side, I saw
```
[ 89%] Linking CXX shared library ../../../../../lib/libomptarget.rtl.cuda.so
[ 90%] Linking CXX shared library ../../../../../lib/libomptarget.rtl.amdgpu.so
-- Installing:
jhuber6 wrote:
> @jhuber6 unfortunately after
> [2fb764d](https://github.com/llvm/llvm-project/commit/2fb764d2dae288f24335dfc168b5491a1017fc83)
>
> ```
> ls
> /soft/compilers/llvm/master-nightly/lib/x86_64-unknown-linux-gnu/libomptarget.rtl*
>
ye-luo wrote:
@jhuber6 unfortunately after 2fb764d2dae288f24335dfc168b5491a1017fc83
```
ls
/soft/compilers/llvm/master-nightly/lib/x86_64-unknown-linux-gnu/libomptarget.rtl*
/soft/compilers/llvm/master-nightly/lib/x86_64-unknown-linux-gnu/libomptarget.rtl.cuda.so
jhuber6 wrote:
> It seems being installed twice both under `lib` and
> `lib/x86_64-unknown-linux-gnu`. files are the identical as diff show nothing.
Makes sense, like `add_llvm_library` is implicitly installing it there, then
our subsequent `install` call is doing it again. I wonder if
ye-luo wrote:
It seems being installed twice both under `lib` and
`lib/x86_64-unknown-linux-gnu`. files are the identical as diff show nothing.
https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
> ```
> yeluo@epyc-server:/soft/llvm/main-20240301/lib$ ls libomp* -l
> lrwxrwxrwx 1 yeluo yeluo 34 Mar 1 11:18 libomptarget.rtl.amdgpu.so ->
> libomptarget.rtl.amdgpu.so.19.0git
> -r--r--r-- 1 yeluo yeluo 67532024 Mar 1 11:04
> libomptarget.rtl.amdgpu.so.19.0git
>
ye-luo wrote:
```
yeluo@epyc-server:/soft/llvm/main-20240301/lib$ ls libomp* -l
lrwxrwxrwx 1 yeluo yeluo 34 Mar 1 11:18 libomptarget.rtl.amdgpu.so ->
libomptarget.rtl.amdgpu.so.19.0git
-r--r--r-- 1 yeluo yeluo 67532024 Mar 1 11:04
libomptarget.rtl.amdgpu.so.19.0git
lrwxrwxrwx 1 yeluo
jhuber6 wrote:
> Problem 1 can be solved by flipping the order. But Problem 2 would remain as
> it doesn't depend on the order.
https://github.com/llvm/llvm-project/pull/83573 I made a patch to fix it.
https://github.com/llvm/llvm-project/pull/83282
jhuber6 wrote:
> Problem 1 can be solved by flipping the order. But Problem 2 would remain as
> it doesn't depend on the order.
Honestly, we should just remove the second test. We just treat these things as
libraries and it doesn't make sense for a test to ensure that `-lstdc++`
doesn't
bjope wrote:
Problem 1 can be solved by flipping the order.
But Problem 2 would remain as it doesn't depend on the order.
https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
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
bjope 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
`//
https://github.com/jhuber6 closed
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
https://github.com/MaskRay approved this pull request.
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
@@ -2763,13 +2763,13 @@ void tools::addOpenMPDeviceRTL(const Driver ,
const llvm::opt::ArgList ,
llvm::opt::ArgStringList ,
StringRef BitcodeSuffix,
-
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Joseph Huber (jhuber6)
Changes
Summary:
One recurring problem we have with the OpenMP libraries is that they are
potentially conflicting with ones found on the system, this occurs when
there are two copies and one is used for
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/83282
Summary:
One recurring problem we have with the OpenMP libraries is that they are
potentially conflicting with ones found on the system, this occurs when
there are two copies and one is used for linking that it
28 matches
Mail list logo
