Add CI check when building sysroot with GCC backend and running libcore tests with it

[GuillaumeGomez]

Fixes rust-lang/rustc_codegen_gcc#882.

Is it what you had in mind @Kobzol?

r? @Kobzol

[rustbot]

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

[lqd]

I don’t know this job and haven’t checked, but would overriding these env vars skip the work it’s doing now, instead of adding new work?

[GuillaumeGomez]

The point is to redo the whole work. That was part of the discussion I had with @Kobzol (which surprised me). But in the end, we decided to make the change and see the impact on the total runtime.

[lqd]

I mean, these are env vars, not commands in a script, they may just be describing what to run and not how many times or redo the whole work. So I wonder if both tests were run, or just the one in the last value in that env var? I guess the logs should show that.

[antoyo]

I mean, these are env vars, not commands in a script, they may just be describing what to run and not how many times or redo the whole work. So I wonder if both tests were run, or just the one in the last value in that env var? I guess the logs should show that.

Is there any way to see which sysroot (std compiled with cg_gcc or cg_llvm) is used from the logs?

[rust-log-analyzer]

The job x86_64-gnu-gcc failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

DirectMap4k:      121984 kB
DirectMap2M:     5115904 kB
DirectMap1G:    13631488 kB
##[endgroup]
Executing python3 ../x.py   --stage 1   test library/core  --set rust.optimize=false  --set rust.optimize-tests=false  --set rust.debug-assertions=false  --set rust.codegen-backends=[\"gcc\"]
+ python3 ../x.py --stage 1 test library/core --set rust.optimize=false --set rust.optimize-tests=false --set rust.debug-assertions=false --set rust.codegen-backends=["gcc"]
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.05s
##[endgroup]
WARNING: setting `optimize` to `false` is known to cause errors and should be considered unsupported. Refer to `bootstrap.example.toml` for more details.
WARNING: when using `download-ci-llvm`, the local `llvm.libzstd` option, like almost all `llvm.*` options, will be ignored and set by the LLVM CI artifacts builder config.
---
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
---- array::array_map_drop_safety stdout end ----
---- array::array_map_drops_unmapped_elements_on_panic stdout ----

thread 'array::array_map_drops_unmapped_elements_on_panic' (18874) panicked at library/coretests/tests/array.rs:707:17:
assertion failed: x.0 < panic_after
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt.localalias
   2: core::panicking::panic.localalias
   3: coretests::array::array_map_drops_unmapped_elements_on_panic
---
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt.localalias
   2: core::panicking::assert_failed_inner.localalias
   3: core::panicking::assert_failed::<usize, usize>.localalias
   4: <coretests::array::array_map_drops_unmapped_zst_elements_on_panic::{closure#0} as core::ops::function::FnOnce<()>>::call_once.cold
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
---- array::array_map_drops_unmapped_zst_elements_on_panic stdout end ----
---- lazy::lazy_force_mut_panic stdout ----
---- lazy::lazy_force_mut_panic stdout end ----

For more information how to resolve CI failures of this job, visit this link.