Update openmp/offload to new LLVM-22 build setup

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[ZuseZ4]

I'm just testing the libc-gpu build as well, will push an update later.

cc @jhuber6 Does that look like what you have in mind? I'm running all 3 reusing the same output directory (out_dir). I know I shouldn't do that for higher level differences like llvm vs omp/offload builds, but when just having different targets it seems to work fine (?)

cc @Sa4dUs can you test this please for nvidia?

blocked-on LLVM rc3 in #152428, which should include: llvm/llvm-project#179375

blocked on LLVM RC-final, which should include llvm/llvm-project#181048

[jhuber6]

offload won't work targeting a GPU. I made a change to silently accept this upstream but I don't think you're on that.

[ZuseZ4]

I tried it, but I don't think it's worth backporting. Fwiw this config works locally without your LLVM PR.

[ZuseZ4]

So, with the vendored llvm patch (it's backport will be in the next Release candidate in 2 weeks) I can now locally build libc-for-gpu, which is the last piece that I had to postpone so far. Now it finishes the llvm and ompoffload/libc build steps.

[ZuseZ4]

@jieyouxu I rebased one the latest llvm, which had another backport for us.
I got it to work in one config, but the main setup for local builds now still fails. That is, if someone sets clang = true and offload = true.

The problem is simply, that we want to compile libc-for-gpu with a nvptx/amdgcn as targets.
We don't want a full cross-compilation of rustc, so we have x86 as target.
That works for all other omp/offload libraries, but libc-for-gpu breaks if we try to compile it for x86, which is fair.
I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

This runs into the following assertion:

Building OpenMP/Offload for x86_64-unknown-linux-gnu
thread 'main' (868937) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `TARGET` not defined
build script failed, must exit now

I also tried to hardcode it as amdgcn-amd-amdhsa. This resulted in

Building OpenMP/Offload for x86_64-unknown-linux-gnu
CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
TARGET_CMAKE_TOOLCHAIN_FILE = None
CMAKE_TOOLCHAIN_FILE = None
thread 'main' (831028) panicked at /g/g90/drehwald1/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
environment variable `CARGO_CFG_TARGET_OS` not defined
build script failed, must exit now

I experimented a bit with setting CARGO_CFG_TARGET_{OS|ARCH}, but that just lead to more bugs.
Do you know a somewhat clean solution to this?

[jieyouxu]

(I'll try to take a look this weekend)

[jieyouxu]

Discussion: unfortunately I'm not sure.

I tried to remove the line where we set the target in configure_cmake (cfg.target(&target.triple).host(&builder.config.host_target.triple);), so libc-for-gpu could guess its GPU target, and rust bootstrap on the other hand isn't "surprised" by a different target.

I wonder if you are running into something like #138784 or rust-lang/cmake-rs#242 where cmake-rs isn't really equipped to handle cross-compilation outside of build.rs (i.e. used as a runtime library)?

[ZuseZ4]

I like that we're both here being unsure about a cmake change, while you link an issue about two other rustc devs being unsure about a cmake change. I see a common pattern here :D

@madsmtm it looks like you've been involved in some related issues. I have a single cmake invocation (out of 3 or 4) during bootstrap where I want the cpu target to either not be printed, or replace it once with a gpu target. Is there a way to achieve that?

[jieyouxu]

That makes 4 in total 😆

[ZuseZ4]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

I also rebased and re-tested it in both combinations (enabling the clang project which is the normal local workflow, and with an external clang/llvm which is our CI workflow).

libc still uses the compiler name as a C++ namespace, which breaks since rust uses a . in our compiler name (1.96). I undefine and redefine it which breaks if you ctrl-C during the build and re-start (since it doesn't re-undefine the old name), but there should be a tracked variable for it.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jieyouxu]

Changes seem okay, one FIXME request. You can r=me after.

View changes since this review

[jieyouxu]

Ok. Since we already know that we don't understand it, I did the only reasonable thing: I didn't change anything and recompiled. It now works.

To be clear, our current behaviour of setting the target to the host cpu when we compile libc (or some of the other gpu projects here) for a gpu is wrong, but we don't seem to know how to resolve that properly and it works for now, so I'll take that.

Can you leave that as an FIXME in the code / tracked as an issue somewhere?

[rust-bors]

☔ The latest upstream changes (presumably #160645) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.