antoyo

joined 2 years ago
[–] antoyo 2 points 3 days ago (1 children)

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.

[–] antoyo 1 points 4 days ago

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.

[–] antoyo 1 points 5 days ago (3 children)

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

[–] antoyo 1 points 5 days ago (5 children)

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.

 

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

[–] antoyo 1 points 4 months ago

Thanks for sponsoring me: I really appreciate.

I only ever worked on this project part time.

17
submitted 4 months ago by antoyo to c/rust
 

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

[–] antoyo 1 points 9 months ago

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.

26
submitted 9 months ago by antoyo to c/rust
 

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.

21
submitted 11 months ago by antoyo to c/rust
 

We fixed a couple of bugs and improved the support for Aarch64 which was requested by some people.

17
submitted 1 year ago by antoyo to c/rust
 

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.

[–] antoyo 3 points 2 years ago

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

[–] antoyo 2 points 2 years ago (2 children)

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?

 

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!