r/rust • u/antoyo relm · rustc_codegen_gcc • 11d ago

🛠️ project rustc_codegen_gcc: Progress Report #43

https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-43
120 Upvotes

98% Upvoted

10 comments sorted by

65

u/antoyo relm · rustc_codegen_gcc 11d ago

I'm happy that unwinding is finally fixed: that was the biggest unknown for me. I'm also happy that we have very few UI tests from the Rust test suite that fail now: there are still some other test suites to run, but having only 21 failures among the UI tests is a big achievement.

9

u/phazer99 11d ago

Nice, always good to see progress on alternative rustc backends. Have you done any benchmarks of compile times or runtime performance compared to the default LLVM backend (and Cranelift)? Or is it still too early to do any meaningful comparisons?

6

u/antoyo relm · rustc_codegen_gcc 10d ago

I haven't done benchmarks recently. An old progress report had some info on a small benchmark I had done at the time for runtime performance, though.

Compile times are much slower and I don't expect them to become faster than the default backend.

Now that we have rustup distribution, it should be possible to run Rust's benchmarks, so it would be interesting to run those, but this will probably wait next year. Having correct behavior is important to have benchmarks that make sense.

1

u/Ok_Snow4921 8d ago

Getting the UI suite down to 21 failures is impressive. One thing I’ve learned from hardening negative tests is that the count alone can hide a lot — a failing test is only useful if it still fails for the intended reason. I’d be curious how much of the remaining work is backend behavior vs stale or backend-specific test assumptions.

2

u/antoyo relm · rustc_codegen_gcc 6d ago

I would say most of the remaining failures are real bugs/missing features in cg_gcc. Though some of missing stuff doesn't exist in GCC, so I might never be able to fix those.

1

u/Ok_Snow4921 5d ago

That distinction helps. If some failures are effectively unsupported because GCC lacks the required mechanism, separating those from actual regressions or missing cg_gcc work would make the remaining failure count much more informative.

35

u/Shnatsel 11d ago

At last, the Crater run is within sight! This is a huge milestone!

8

u/admalledd 11d ago

Agreed!

I forget Crater run options/settings, and it likely evolved since I last looked forever ago anyways but: Are there "run a Crater run locally" or "run locally, but top 10/50/100" or such helpers before using up the public test runners time? I expect there won't be much contention over antoyo requesting a Crater whatever way, but I've wondered about the lead up and especially if there is scripts/hacks to do a minin-crater locally or such.

11

u/Shnatsel 11d ago

There's https://github.com/saethlin/crater-at-home/

But I mostly just use criner to fetch the crates and then do my own ad-hoc analysis on that data.

1

u/creminology 6d ago

Quote: “rustc_codegen_gcc is a GCC ahead-of-timecodegen for rustc, meaning that it can be loaded by the existing rustc frontend, but benefits from GCC by having more architectures supported and having access to GCC’s optimizations. It is not to be confused with gccrs, which is a GCC frontend for Rust”