Rustc_codegen_GCC can now run libcore’s tests and pass most of them | Hacker News Reader

Rustc_codegen_GCC can now run libcore’s tests and pass most of them

blog.antoyo.xyz

134 pointstodsacerdoti15 comments

This is a GCC codegen backend for rustc, so it gets to reuse the existing Rust frontend for free, but benefits from GCC's optimizations and support for more target architectures.

Contrast with GCC Rust (https://thephilbert.io/2021/05/14/gcc-rust-weekly-status-rep...), which is attacking the problem from the other side by building a GCC Rust frontend in C++. That one will help with bootstrapping, which currently has to go through mrustc and many rustc builds.

It's very nice to see both of these progressing :)

Seems like mrustc is up to 1.39:

https://github.com/thepowersgang/mrustc

Does the bootstrapping require every single step up to the current rustc or can it skip some steps?

It looks like this bootstrap chain script goes through each stable version in turn, although it hasn’t been updated to latest mrustc: https://android.googlesource.com/platform/prebuilts/rust/+/r....

You can bootstrap up at least 1.50 https://gitlab.com/stikonas/gentoo-bootstrap/-/tree/master/d... (latest release is 1.52.1 so not too far off)

> Contrast with GCC Rust (https://thephilbert.io/2021/05/14/gcc-rust-weekly-status-rep...), which is attacking the problem from the other side by building a GCC Rust frontend in C++. That one will help with bootstrapping, which currently has to go through mrustc and many rustc builds.

Wouldn't it depend on what kind of bootstrapping? It doesn't help with trusting trust, but rustc frontend + gcc backend would help with porting to a new platform, wouldn't it?

Yes it would help with porting to a platform which is supported by GCC but not supported by LLVM.

For a new platform it doesn't change anything. By definition neither GCC nor LLVM supports a new platform since it is new.

Note that GCC Rust won't help any more with bootstrapping than mrustc can help. Getting one rustc version to compile is only the start of a long process of following the evolution of the language and implementing weird implementation behaviours the compiler now relies on for its own compilation.

You have to provide constant upkeep, and for that both mrustc and GCC Rust are suited equally well. On the other hand, rustc_codegen_gcc is way better suited for following the moving target, but obviously it can't be used for bootstrapping as it's written in Rust.

Anyone have any comparison benchmarks? I'd love to see how GCC measures up to LLVM when it comes to Rust binaries.

I'm also curious if the resulting binary size is any different.

The article says, “This project is currently at the point where many programs can be compiled, but run incorrectly,” so comparing benchmarks at this point would probably be very misleading.

It's too soon for that.

Would be nice if there was a bigger effort to make cross compilation actually useable with rust/cargo...basic stuff like cross compiling for a x86_64 target from a x86_64 host still isn't really supported yet.

What do you mean? Which of those steps doesn't work for you? <https://rust-lang.github.io/rustup/cross-compilation.html>

Probably they mean using the gcc backend. That seems like a huge hassle, but might be possible if rustup would distribute libgccjit configured for different architectures.

Is it possible yet to have Rust compile itself?

I believe that's the goal of Cranelift [1] and rustc's cg_clif [2].

1: https://github.com/bytecodealliance/wasmtime/tree/main/crane...

2: https://github.com/rust-lang/rust/pull/77975

Reply on news.ycombinator.com