"".split('.') in build.rs with -Cremark=all causes compiler segfault on ARM

[aldanor]

cargo new --bin foo
cd foo
echo "fn main() { _ = \"\".split('.'); }" >build.rs
RUSTFLAGS="-Cremark=all -Cdebuginfo=1" cargo +nightly build --release

• on M1 macOS (ARM) results in

note: /rustc/.../library/core/src/str/pattern.rs:546:9 gisel-legalize (missed): unable to legalize instruction: G_STORE %26:_(<4 x s8>), %25:_(p0) :: (store (<4 x s8>) into %ir.18, align 8)

error: could not compile `foo` (build script)

Caused by:
  process didn't exit successfully: `rustc --crate-name build_script_build --edition=2021 build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=323 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C metadata=01a3112ac4ce4489 -C extra-filename=-01a3112ac4ce4489 --out-dir target/debug/build/foo-01a3112ac4ce4489 -C incremental=foo/target/debug/incremental -L dependency=target/debug/deps -Cremark=all -Cdebuginfo=1`

(signal: 11, SIGSEGV: invalid memory reference)

• on c7g AWS instance (ARM) results in

note: /rustc/.../library/core/src/str/pattern.rs:543:0 size-info (analysis): AArch64O0PreLegalizerCombiner: Function: _ZN52_$LT$char$u20$as$u20$core..str..pattern..Pattern$GT$13into_searcher17h670b9d7d5e22c8caE: MI Instruction count changed from 43 to 40; Delta: -3

note: /rustc/.../library/core/src/str/pattern.rs:546:9 gisel-legalize (missed): unable to legalize instruction: G_STORE %26:_(<4 x s8>), %25:_(p0) :: (store (<4 x s8>) into %ir.18, align 8)

error: rustc interrupted by SIGSEGV, printing backtrace

• on c6i AWS instance (x64) compiles fine

(was randomly discovered while trying out cargo-remark which makes use of LLVM remarks)

A few notes of interest:

• This crashes on both M1 (ARM, macOS) and c7g (ARM, Linux); works on x64 Linux
• Seems to happen for both debug and release builds
• Interestingly enough, if you replace '.' with ".", it won't crash

[Noratrieb]

cc @Kobzol

[Kobzol]

@aldanor could you please try with some nightly from June 2023 or sooner? I wonder if this might be related to the remark changes I made, although the error is there even without using the new remark output machinery.

I don't have an ARM machine at hand to debug this.

[aldanor]

Ok, there you go:

• rustc 1.72.0-nightly (e6d4725c7 2023-06-05) = ✅
• rustc 1.72.0-nightly (b2b34bd83 2023-06-06) = ☠️

That should narrow it down pretty well.

e6d4725...b2b34bd

[Kobzol]

Thanks! That narrows it down indeed, e.g. the LLVM upgrade looks suspicious.

If you still want to devote some time to helping bisecting this, could you please run this:

$ RUSTFLAGS="-Cremark=all -Cdebuginfo=1" cargo bisect-rustc --start=2023-06-04 --end=2023-06-07 -- build --release

using the cargo-bisect-rustc tool? That should help bisecting it down to a single PR/compiler build.

[aldanor]

using the cargo-bisect-rustc tool? That should help bisecting it down to a single PR/compiler build.

@Kobzol for whatever reason, cargo-bisect-rustc says there's no regressions even if I point it at today's end date - while running it from the command line clearly fails...

[Kobzol]

Hmm, maybe it does not respects RUSTFLAGS or something like that. You can put the build code into a script, and then use --script (https://rust-lang.github.io/cargo-bisect-rustc/usage.html#scripting) option to let the tool know if it crashes or not.

[aldanor]

You can put the build code into a script, and then use --script

That's what I thought too, already tried. 🤔

[aldanor]

... I could try with git-bisect but have zero experience building and using rustc from scratch in cases like this.

[aldanor]

Ok, wrote a little bisecting script, rebuilding rustc from source manually and rerunning the above; was a bit tedious but it worked (still no idea why cargo bisect-rustc --script doesn't work but that's a separate question).

Here's the commit that breaks it: fd9bf59 (and here's the PR: #111999).

[Kobzol]

Thanks a lot!

CC @scottmcm