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:
undefined
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.
I've been pretty busy in my life recently, but I finally got around writing this blog post. Hopefully, things are sorted out in my personal life and I should be able to be more regular about these updates in the future.
I'm very happy to see good progress towards rustup distribution (thanks to Kobzol again!).
Thanks for sponsoring me: I really appreciate.
I only ever worked on this project part time.
I'm happy to have received reviews and merged more than 10 patches to GCC lately (12, to be exact). There are around 6 left to merge (and a couple of others to send to the mailing list).
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.
We finally were able to finish the sync with the Rust compiler and now support the types f16 and f128!
I had a lot of stuff going on lately in my private life, so I wasn't able to work as much as I wanted on rustc_codegen_gcc. Hopefully, it should be back to normal after my vacation.
We fixed a couple of bugs and improved the support for Aarch64 which was requested by some people.
We now run part of the tests in the Rust repo's CI, which is the first step to eventually distributing the GCC codegen via rustup! We also improved a lot the cross-compilation situation.
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?
Antoyo's Personal Blog
We just accomplished two big milestones:
- We can now compile Rust for Linux without any patches to cg_gcc.
- We can compile, run and pass all the tests from the most popular crates. This is huge!