Skip to content

Conversation

@Kobzol
Copy link
Member

@Kobzol Kobzol commented Jan 15, 2026

This PR adds the GCC codegen backend, and the GCC (libgccjit) component upon which it depends, to build-manifest, and thus also to (nightly) Rustup. I added both components in a single PR, because one can't work/isn't useful without the other.

Both components are marked as nightly-only and as -preview.

As a reminder, the GCC component is special; we need a separate component for every (host, target) compilation pair. This is not something that is really supported by rustup today, so we work around that by creating a separate component/package for each compilation target. So if we want to distribute GCC that can compile from {T1, T2} to {T2, T3}, we will create two separate components (gcc-T2 and gcc-T3), and make both of them available on T1 and T2 hosts.

I tried to reuse the existing structure of PkgType in build-manifest, but added a target field to the Gcc package variant. This required some macro hackery, but at least it doesn't require making larger changes to build-manifest.

After this PR lands, unless I messed something up, starting with the following nightly, the following should work:

rustup +nightly component add rustc-codegen-gcc-preview gcc-x86_64-unknown-linux-gnu-preview
RUSTFLAGS="-Zcodegen-backend=gcc" cargo +nightly build

Note that it will work currently only on x86_64-unknown-linux-gnu, and only if not cross-compiling.

r? @Mark-Simulacrum

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jan 15, 2026
@Mark-Simulacrum
Copy link
Member

Both components are marked as nightly-only and as -preview.

Can you confirm this is real preview? Historically I'm not sure we've had any components we actually managed to make installable only with -preview (by accident).

@bors try=dist-x86_64-linux

(Is that the right way to get a full dist build? If so I can kick a dev-static run off with the artifacts once it completes).

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 16, 2026

Unknown command "try". Run @bors help to see available commands.

@Kobzol
Copy link
Member Author

Kobzol commented Jan 16, 2026

@bors try jobs=dist-x86_64-linux

@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Jan 16, 2026
Add GCC and the GCC codegen backend to build-manifest and rustup


try-job: dist-x86_64-linux
@Kobzol
Copy link
Member Author

Kobzol commented Jan 16, 2026

Huh, indeed if I do rustup +nightly component add rustc-codegen-gcc, without the -preview suffix, it also works. But the same is indeed true for existing components, like rustc-codegen-cranelift[-preview].

I guess it's because rustup allows both the original name and the renamed name to be installed?

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 16, 2026

☀️ Try build successful (CI)
Build commit: 83ba973 (83ba97395259d495deac3953da60349ecb08f09a, parent: bcf787a7805d6f26586409eb0ed7e4a739c7d687)

@Mark-Simulacrum
Copy link
Member

Kicked off dev-static nightly with ./release-scripts/promote-release.py release dev nightly 83ba97395259d495deac3953da60349ecb08f09a.

@Mark-Simulacrum
Copy link
Member

Looks released (didn't check for gcc presence): RUSTUP_DIST_ROOT=https://dev-static.rust-lang.org rustup update nightly to access it.

I guess it's because rustup allows both the original name and the renamed name to be installed?

Seems likely. I don't have a super strong opinion on whether we should try to "fix" that for gcc specifically -- maybe not -- but I think it's worth knowing when we describe state of the world. One option we've done elsewhere is to restrict creating the component on non-nightly channels (e.g., miri does this). That might make sense while we're still iterating -- it's another form of preview.

@Kobzol
Copy link
Member Author

Kobzol commented Jan 21, 2026

It works! 🎉

$ RUSTUP_DIST_ROOT=https://dev-static.rust-lang.org rustup toolchain install nightly --component gcc-x86_64-unknown-linux-gnu-preview --component rustc-codegen-gcc-preview

$ cargo new foo
$ RUSTFLAGS="-Zcodegen-backend=gcc" cargo +nightly run
Compiling foo v0.1.0 (/tmp/foo)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.26s
     Running `target/debug/foo`
Hello, world!

$ readelf -p .comment target/debug/foo
String dump of section '.comment':
  [     0]  rustc version 1.94.0-nightly (83ba97395 2026-01-16)
  [    34]  rustc version 1.94.0-nightly (83ba97395 2026-01-16) with libgccjit 16.0.0
  [    7e]  GCC: (GNU) 16.0.0 20251008 (experimental)
  [    a9]  Linker: LLD 21.1.8 (/checkout/src/llvm-project/llvm 00d23d10dc48c6bb9d57ba96d4a748d85d77d0c7)
  [   107]  GCC: (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.

One option we've done elsewhere is to restrict creating the component on non-nightly channels (e.g., miri does this). That might make sense while we're still iterating -- it's another form of preview.

Yup, we already do that! The GCC and cg-gcc components cannot be disted outside of nightly/dev channels, and cg-gcc was marked as NIGHTLY_ONLY in build-manifest. I forgot to do that for GCC though, so good catch! Did that in the latest commit.

@Mark-Simulacrum
Copy link
Member

r=me if we're happy with testing done so far. I think we should add a note about preview to a tracking issue of some kind, though we'll probably remember to think about it regardless.

@Kobzol
Copy link
Member Author

Kobzol commented Jan 21, 2026

Created a tracking issue in #151460.

In terms of testing, it seems to work on hello world. The GCC backend is far from complete, so some ICEs are likely bound to happen, but since it's a nightly-only preview component, I think that's expected.

@bors r=Mark-Simulacrum

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 21, 2026

📌 Commit f4834cf has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 21, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jan 21, 2026
…rk-Simulacrum

Add GCC and the GCC codegen backend to build-manifest and rustup

This PR adds the GCC codegen backend, and the GCC (libgccjit) component upon which it depends, to build-manifest, and thus also to (nightly) Rustup. I added both components in a single PR, because one can't work/isn't useful without the other.

Both components are marked as nightly-only and as `-preview`.

As a reminder, the GCC component is special; we need a separate component for every (host, target) compilation pair. This is not something that is really supported by rustup today, so we work around that by creating a separate component/package for each compilation target. So if we want to distribute GCC that can compile from {T1, T2} to {T2, T3}, we will create two separate components (`gcc-T2` and `gcc-T3`), and make both of them available on T1 and T2 hosts.

I tried to reuse the existing structure of `PkgType` in `build-manifest`, but added a target field to the `Gcc` package variant. This required some macro hackery, but at least it doesn't require making larger changes to `build-manifest`.

After this PR lands, unless I messed something up, starting with the following nightly, the following should work:
```bash
rustup +nightly component add rustc-codegen-gcc-preview gcc-x86_64-unknown-linux-gnu-preview
RUSTFLAGS="-Zcodegen-backend=gcc" cargo +nightly build
```

Note that it will work currently only on `x86_64-unknown-linux-gnu`, and only if not cross-compiling.

r? @Mark-Simulacrum
rust-bors bot pushed a commit that referenced this pull request Jan 21, 2026
…uwer

Rollup of 5 pull requests

Successful merges:

 - #151010 (std: use `ByteStr`'s `Display` for `OsStr`)
 - #151156 (Add GCC and the GCC codegen backend to build-manifest and rustup)
 - #151219 (Fixed ICE when using function pointer as const generic parameter)
 - #151343 (Port some crate level attrs to the attribute parser)
 - #151463 (add x86_64-unknown-linux-gnuasan to CI)

r? @ghost
@rust-bors rust-bors bot merged commit d6c7861 into rust-lang:main Jan 22, 2026
11 checks passed
@rustbot rustbot added this to the 1.95.0 milestone Jan 22, 2026
rust-timer added a commit that referenced this pull request Jan 22, 2026
Rollup merge of #151156 - Kobzol:build-manifest-cg-gcc, r=Mark-Simulacrum

Add GCC and the GCC codegen backend to build-manifest and rustup

This PR adds the GCC codegen backend, and the GCC (libgccjit) component upon which it depends, to build-manifest, and thus also to (nightly) Rustup. I added both components in a single PR, because one can't work/isn't useful without the other.

Both components are marked as nightly-only and as `-preview`.

As a reminder, the GCC component is special; we need a separate component for every (host, target) compilation pair. This is not something that is really supported by rustup today, so we work around that by creating a separate component/package for each compilation target. So if we want to distribute GCC that can compile from {T1, T2} to {T2, T3}, we will create two separate components (`gcc-T2` and `gcc-T3`), and make both of them available on T1 and T2 hosts.

I tried to reuse the existing structure of `PkgType` in `build-manifest`, but added a target field to the `Gcc` package variant. This required some macro hackery, but at least it doesn't require making larger changes to `build-manifest`.

After this PR lands, unless I messed something up, starting with the following nightly, the following should work:
```bash
rustup +nightly component add rustc-codegen-gcc-preview gcc-x86_64-unknown-linux-gnu-preview
RUSTFLAGS="-Zcodegen-backend=gcc" cargo +nightly build
```

Note that it will work currently only on `x86_64-unknown-linux-gnu`, and only if not cross-compiling.

r? @Mark-Simulacrum
@Kobzol Kobzol deleted the build-manifest-cg-gcc branch January 22, 2026 07:46
@Kobzol
Copy link
Member Author

Kobzol commented Jan 22, 2026

Should be available on nightly starting from 23 January 2026.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 24, 2026
…lacrum

Extend build-manifest local test guide

Fill in more blanks about how to test build-manifest changes with Rustup.

Figured this out while working on rust-lang#151156, with the help of bjorn3.
rust-timer added a commit that referenced this pull request Jan 25, 2026
Rollup merge of #151157 - Kobzol:build-manifest, r=Mark-Simulacrum

Extend build-manifest local test guide

Fill in more blanks about how to test build-manifest changes with Rustup.

Figured this out while working on #151156, with the help of bjorn3.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jan 25, 2026
Extend build-manifest local test guide

Fill in more blanks about how to test build-manifest changes with Rustup.

Figured this out while working on rust-lang/rust#151156, with the help of bjorn3.
github-actions bot pushed a commit to rust-lang/stdarch that referenced this pull request Jan 26, 2026
Extend build-manifest local test guide

Fill in more blanks about how to test build-manifest changes with Rustup.

Figured this out while working on rust-lang/rust#151156, with the help of bjorn3.
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Jan 26, 2026
Extend build-manifest local test guide

Fill in more blanks about how to test build-manifest changes with Rustup.

Figured this out while working on rust-lang/rust#151156, with the help of bjorn3.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants