Update openmp/offload to new LLVM-22 build setup by ZuseZ4 · Pull Request #152011 · rust-lang/rust

ZuseZ4 · 2026-02-02T21:50:45Z

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 · 2026-02-02T22:16:28Z

src/bootstrap/src/core/build_steps/llvm.rs

+                .profile(profile)
+                .env("LLVM_CONFIG_REAL", &host_llvm_config)
+                .define("LLVM_ENABLE_ASSERTIONS", "ON")
+                .define("LLVM_ENABLE_RUNTIMES", "openmp;offload")


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.

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

src/bootstrap/src/core/build_steps/llvm.rs

ZuseZ4 · 2026-02-12T18:14:54Z

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 · 2026-02-27T22:34:41Z

@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 · 2026-03-10T12:16:24Z

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

jieyouxu · 2026-03-14T11:12:35Z

src/bootstrap/src/core/build_steps/llvm.rs

+                cfg.define("LIBC_INCLUDE_BENCHMARKS", "OFF");
+                cfg.define("LIBC_TARGET_TRIPLE", omp_target);
+                cfg.define("LLVM_LIBC_FULL_BUILD", "ON");
+                cfg.define("LLVM_ENABLE_RUNTIMES", "openmp;libc");


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

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?

That makes 4 in total 😆

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.

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 · 2026-03-18T19:44:03Z

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 · 2026-03-19T01:22:42Z

src/bootstrap/src/core/build_steps/llvm.rs

+                cfg.define("LIBC_INCLUDE_BENCHMARKS", "OFF");
+                cfg.define("LIBC_TARGET_TRIPLE", omp_target);
+                cfg.define("LLVM_LIBC_FULL_BUILD", "ON");
+                cfg.define("LLVM_ENABLE_RUNTIMES", "openmp;libc");


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?

ZuseZ4 added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) F-gpu_offload `#![feature(gpu_offload)]` labels Feb 2, 2026

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 2, 2026

jhuber6 reviewed Feb 2, 2026

View reviewed changes

ZuseZ4 commented Feb 3, 2026

View reviewed changes

src/bootstrap/src/core/build_steps/llvm.rs Outdated Show resolved Hide resolved

jieyouxu self-assigned this Feb 3, 2026

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Feb 3, 2026

This comment has been minimized.

Sign in to view

ZuseZ4 force-pushed the update-offload-bootstrap branch from 1a6f0e4 to a85f0aa Compare February 6, 2026 00:49

This comment has been minimized.

Sign in to view

ZuseZ4 force-pushed the update-offload-bootstrap branch from a85f0aa to 3becbd2 Compare February 12, 2026 18:05

This comment has been minimized.

Sign in to view

ZuseZ4 force-pushed the update-offload-bootstrap branch from 3becbd2 to 4e818c9 Compare February 27, 2026 20:35

ZuseZ4 marked this pull request as ready for review February 27, 2026 22:42

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 27, 2026

jieyouxu reviewed Mar 14, 2026

View reviewed changes

add libc-for-gpu now that llvm-22 rc3 landed

c462c5b

ZuseZ4 force-pushed the update-offload-bootstrap branch from 4e818c9 to c462c5b Compare March 18, 2026 19:43

jieyouxu approved these changes Mar 19, 2026

View reviewed changes

jieyouxu added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 19, 2026

Uh oh!

Conversation

ZuseZ4 commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jhuber6 Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

ZuseZ4 Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

ZuseZ4 commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

ZuseZ4 commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jieyouxu commented Mar 10, 2026

Uh oh!

jieyouxu Mar 14, 2026

Choose a reason for hiding this comment

Uh oh!

ZuseZ4 Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jieyouxu Mar 15, 2026

Choose a reason for hiding this comment

Uh oh!

ZuseZ4 Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

jieyouxu Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Mar 18, 2026

Uh oh!

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jieyouxu Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ZuseZ4 commented Feb 2, 2026 •

edited

Loading

ZuseZ4 commented Feb 12, 2026 •

edited

Loading

ZuseZ4 commented Feb 27, 2026 •

edited

Loading

ZuseZ4 Mar 14, 2026 •

edited

Loading

jieyouxu left a comment •

edited by rustbot

Loading