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).

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.

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.

What do you think it means?

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.

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.

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

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.

Thanks for sponsoring me: I really appreciate.

I only ever worked on this project part time.

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.

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

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?