Oh, sorry for the confusion: this is about rustc_codegen_gcc which is a codegen plugin for rustc that uses libgccjit to generate the object files via GCC instead of LLVM, so it still requires rustc. There's another project that is a GCC frontend, called gccrs. Also, bootstrap is overloaded: in this case, a full bootstrap means that we can compile the Rust compiler with rustc_codegen_gcc, producing a stage-2 compiler, then recompile the Rust compiler with this stage-2 compiler to get a stage-3 compiler and those 2 compares as equal.

Would you expect the backend to be fully ready by the end of the year?

It depends what you mean by "fully ready", but this is unlikely. By "fully ready", do you mean feature-complete, without any known bugs, working on all GCC targets? Even with only x86-64, I don't expect to have all features: for instance, I don't plan on adding support for sanitizers/code coverage/PGO this year. And some stuff is outside my control: for instance, this Rust PR that will allow me to fix some ABI issues (unblocking, among other things, Aarch64) is waiting for review.

Or are there big/complicated blockers that remain, or LLVM-isms that make full or nearly full parity impossible?

Nothing complicated remains as far as I know. I don't think LLVM-isms is an issue anymore, so I would expect close to full parity to be possible (expect maybe supporting Thin LTO). The big remaining tasks are:

• Support for other architectures than x86-64 (and for SIMD on those targets)
• Debug info
• ABI parity

Relatedly, cranelift cg early struggles had to do, in part, with intrinsics support. I remember talk of somehow solving the problem systemically and not having to implement all of them in the backends directly? Where did things end up regarding that, and how does this backend deal with this problem?

There are Rust intrinsic fallbacks now, but I do not think all intrinsics have a fallback. And I'm not sure this applies to platform intrinsics.

And finally, using evcxr with :timing enabled, and switching between backends with :codegen_backend, I notice that gcc is the slowest when it comes to compile time. Is that because more IR is given to gcc to generate from, or is gcc/libgccjit itself slower now?

Compile times were never been a priority. At first, I thought libgccjit might be slower than GCC since it's not used much, but having used it for another project, it does not seem to be the case. My hunch is that since we need some hacks to convert from the lower-level IR MIR to the higher-level GCC IR, it's going to be hard to generate a very good IR in the end. So, we get a MIR that is not super optimized in terms of compile times and make it worse, so the impact on compile times probably lies there.

Good. I'll attempt to do that for the next update.

Focusing on x86_64 (and linux), can you expand on what’s missing to reach ABI parity?

I haven't look much into it, but perhaps the sret fix mentioned above would fix some issues on x86-64. For the rest, this is mostly bug fixing (we probably don't handle the alignment everywhere) and fuzzing with ABI cafe.

And somewhat relatedly, are you leaning towards publishing an std component built with the backend or not?

I haven't thought much about this, but I guess an idea would be to ship a std for targets not supported by LLVM.

It does actually clean everything. You need to call ./y.sh prepare again if you ran clean all; otherwise, it will fail to find some stuff like rustc-std-workspace-alloc.

I opened an issue to improve the documentation in this regards. Thanks for testing all this: this will help me improve the documentation.

Well, we can generate code for targets not supported by LLVM, but it is not trivial to setup (we hope to get rustup support in the coming months to make this easier) and most GCC targets won't pass as many tests as x86-64 with rustc_codegen_gcc. There's some info in the wiki about some targets that people tried.

It is an optional goal for the Google Summer of Code to bootstrap the rust compiler on other platforms, so we might be able to get a working rustc for new platforms by the end of the summer.

Well, LTO works in many cases, so it's not completely broken. I managed to do a refactoring in this PR, but I'm not entirely satisfied with the results yet (it prints stuff to stderr when LTO is not supported by the gcc installation). I have an idea to workaround this in order to land this PR which should help me continue fixing the issues we have with LTO.

LTO is very complex, though, so this is why it's taking time to move forward on this (same for unwinding support which also works in many cases, but not all).

Do you mean the performance of the tests themselves? If so, how would you suggest that I measure this? By just comparing the execution time?

What do you think it means?

Thanks for sponsoring me: I really appreciate.

I only ever worked on this project part time.

Thanks for reporting this! I cannot reproduce with the following:

y prepare
y build --release
y build
y clean all

(it shows: Successfully ran clean all)

Could you please provide the commands you ran to get this? (It might also be easier for me to track this if you open an issue on GitHub since I don't come here often.)

Also, thanks for the suggestion for better documentation: I created an issue for this.

The issue here is that you didn't provide --build-sysroot to ./y.sh test --release, so it cannot find the std crate.

The setup to be able to use LTO is non-trivial for now (I hope to be able to fix this soon so that liblto_plugin.so is not required for the case where a linker plugin wasn't not asked by the user, which is the default).

You need to have in your path the gcc built with the same version as libgccjit, which contains libexec/gcc/x86_64-pc-linux-gnu/15.0.0/liblto_plugin.so.

Could you please point to the relevant source code for these? From what I could find here, this doesn't seem implemented for the LLVM backend either.

If VFP uses target-specific intrinsics, there's a chance that this doesn't work correctly in the GCC backend yet since our auto-generated mapping we have needs many adjustments and we only added the adjustments for x86-64.