Build GCC on CI #136921
Merged
Build GCC on CI #136921
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
rustbot
added
A-testsuite
This comment has been minimized.
This comment has been minimized.
I think we really should break it out to a separate step |
bjorn3
reviewed
Feb 12, 2025
onur-ozkan
added
S-waiting-on-author
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Feb 14, 2025
Move `llvm.ccache` to `build.ccache` (S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools (rust-lang#136921, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Using.20sccache.20for.20Rust). r? `@onur-ozkan`
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Feb 14, 2025
Move `llvm.ccache` to `build.ccache` (S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools (rust-lang#136921, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Using.20sccache.20for.20Rust). r? ``@onur-ozkan``
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 14, 2025
Rollup merge of rust-lang#136941 - Kobzol:ccache-build, r=onur-ozkan Move `llvm.ccache` to `build.ccache` (S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools (rust-lang#136921, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Using.20sccache.20for.20Rust). r? ``@onur-ozkan``
|
☔ The latest upstream changes (presumably #137001) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
It is apparently required to download GCC dependencies.
|
@rustbot ready Rebased and fixed some CI issues. Let me know what do you think about handling the codegen backend step. |
rustbot
added
S-waiting-on-review
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 22, 2025
Build GCC on CI Previously, we have downloaded a specific commit of GCC and prebuilt it inside Docker using the `build-gccjit.sh` script. This PR removes that scripts and uses the bootstrap GCC step. This allows us to use the `src/gcc` submodule for determining which GCC should be built, and it also moves the logic closer to LLVM, which is also built by bootstrap. A few things to note: - The `sccache` option is currently in the `llvm` block, so the GCC build uses `llvm.ccache`, which is a bit weird :) We could either add `gcc.ccache`, or (what I think would be better) to just move `ccache` to the `build` section, as I don't think that it will be necessary to use ccache for LLVM, but not for GCC. - When the GCC codegen backend is built, it needs to depend on a step that first builds GCC. This is currently done in a hacky way. The proper solution is to create a separate step for the GCC codegen backend, but that is a larger change. Let me know what you think. r? `@onur-ozkan`
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 24, 2025
Build GCC on CI Previously, we have downloaded a specific commit of GCC and prebuilt it inside Docker using the `build-gccjit.sh` script. This PR removes that scripts and uses the bootstrap GCC step. This allows us to use the `src/gcc` submodule for determining which GCC should be built, and it also moves the logic closer to LLVM, which is also built by bootstrap. A few things to note: - The `sccache` option is currently in the `llvm` block, so the GCC build uses `llvm.ccache`, which is a bit weird :) We could either add `gcc.ccache`, or (what I think would be better) to just move `ccache` to the `build` section, as I don't think that it will be necessary to use ccache for LLVM, but not for GCC. - When the GCC codegen backend is built, it needs to depend on a step that first builds GCC. This is currently done in a hacky way. The proper solution is to create a separate step for the GCC codegen backend, but that is a larger change. Let me know what you think. r? `@onur-ozkan` try-job: i686-msvc-1 try-job: x86_64-mingw-1
|
☀️ Try build successful - checks-actions |
|
@bors retry |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 25, 2025
Build GCC on CI Previously, we have downloaded a specific commit of GCC and prebuilt it inside Docker using the `build-gccjit.sh` script. This PR removes that scripts and uses the bootstrap GCC step. This allows us to use the `src/gcc` submodule for determining which GCC should be built, and it also moves the logic closer to LLVM, which is also built by bootstrap. A few things to note: - The `sccache` option is currently in the `llvm` block, so the GCC build uses `llvm.ccache`, which is a bit weird :) We could either add `gcc.ccache`, or (what I think would be better) to just move `ccache` to the `build` section, as I don't think that it will be necessary to use ccache for LLVM, but not for GCC. - When the GCC codegen backend is built, it needs to depend on a step that first builds GCC. This is currently done in a hacky way. The proper solution is to create a separate step for the GCC codegen backend, but that is a larger change. Let me know what you think. r? `@onur-ozkan` try-job: i686-msvc-1 try-job: x86_64-mingw-1
|
☀️ Try build successful - checks-actions |
|
It seems it was spurious... @bors r=onur-ozkan |
|
@bors rollup=never |
|
💡 This pull request was already approved, no need to approve it again.
|
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (a46c755): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 771.258s -> 771.663s (0.05%) |
This was fixed by #136941? |
|
Yeah, I updated the PR description. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, we have downloaded a specific commit of GCC and prebuilt it inside Docker using the
build-gccjit.shscript. This PR removes that scripts and uses the bootstrap GCC step. This allows us to use thesrc/gccsubmodule for determining which GCC should be built, and it also moves the logic closer to LLVM, which is also built by bootstrap.When the GCC codegen backend is built, it needs to depend on a step that first builds GCC. This is currently done in a hacky way. The proper solution is to create a separate step for the GCC codegen backend, but that is a larger change. Let me know what you think.
r? @onur-ozkan
try-job: i686-msvc-1
try-job: x86_64-mingw-1