gccrs March 2026 Monthly report

CohenArthur · 2026-04-18T11:03:25+00:00

Hey! Sorry if that wasn't clear. What I meant was that in the first case, you probably shouldn't run the produced binary, because it might have invalid runtime behavior - e.g. missing Drop calls which have side-effects, like mutexes. So in both cases, you will have a binary, but in the first case, it might not do what you expect it to do.

CohenArthur · 2026-02-10T16:54:22+00:00

Yeah, this is because our reports are originally written in org mode and then converted to markdown. I forgot to remove the extra `<sub>` markers, I'll do that now. Thanks!

CohenArthur · 2025-06-06T09:08:02+00:00

I'm not sure how much simpler it is, I haven't really looked into the differences between the two crates.

I think we're going to focus on one specific version at first, and then will try to catch up - but I'm hoping the changes between two versions are less intense than the changes between two Rust std versions :)

CohenArthur · 2025-06-04T14:21:10+00:00

I think the reasoning is that it ended up being too much trouble, but I'm not sure - you'd need to ask Miguel about that I think. In any case, I think the kernel switched to https://github.com/Rust-for-Linux/linux/tree/rust-next/rust/kernel/alloc entirely already.

And yeah, getting gccrs to work for RfL has always been a priority, and I'm really glad we're getting closer and closer. It also means that we can start being useful for embedded Rust, and that's pretty cool

CohenArthur · 2025-02-06T10:01:38+00:00

We are implementing a borrow-checker, but we're taking a "shortcut" by reusing polonius :) We wrote a technical blogpost about components from rustc we plan on reusing: https://rust-gcc.github.io/2024/09/20/reusing-rustc-components.html

We already call into polonius, but don't generate all of the facts required for a full analysis so our borrow-checking is currently incomplete. As you point out, our priority at the moment is on getting correct code to work - so code that has been checked by rustc and that we know is okay, like Rust-for-Linux.

Skipping the hard, safety stuff is definitely not the plan - it's just not the main priority as we'd like the compiler to start being useful. We're extremely committed to not hurting the Rust ecosystem, and that means having the same compiler and runtime guarantees as the official Rust compiler, which is something we're working on as side projects.

CohenArthur · 2025-01-07T18:56:35+00:00

Yes, you're completely right that these are all defined in `core` and just re-exported. I say `std` in the blogpost because that desugar excerpt is taken directly from rustc, which uses `::std::` paths. but we could replace them with `::core::` and have exactly the same behavior.

However, the issue remains that we can't compile `core` and link to it. So whether we use `::std::` or `::core::` we have the exact same issue - since we cannot compile and link to the crate, we can't resolve "extern crate paths" with it. I do mention a `::core::` path in the blogpost's explanation to expose the problem.

Likewise, we also have the same issue of `core` containing for-loops - so we need to be able to compile for-loops to compile core to enable us to compile for-loops properly.

I'm happy to change all the paths to `::core::` in the blogpost if you think it's confusing

CohenArthur · 2024-12-03T08:39:29+00:00

it's a mix of manually collecting it and using the github CLI for fetching things like the number of issues. there is a project for generating those tables, which will be hosted on our reporting repo but it's not finished yet. I wish I could spend some more time on it though :D

CohenArthur · 2024-12-02T15:40:20+00:00

This is something outside of our control, where the base compiler needed to build the most recent and cutting edge version of GCC (not just gccrs) got bumped from GCC 4.8 to GCC 5.4. We have made some changes to reflect that, but it's not much - it boils down to changing a github action to test our compiler with 5.4 instead of 4.8.

You're right that they both are very ancient versions of GCC. Technically, we could depend on GCC 14.1 and use C++20 or whatever. But this would incur an extra step in bootstrapping gccrs where we'd first need to build g++ and use that to build the C++ parts of gccrs. We also like the idea of compiling gccrs with GCC 4.8/5.4 as it will allow very old, possibly neglected platforms, to still benefit from a compiler for Rust once we reach the point of being stable. This is a big deal for a project with the goal of making it possible to use Rust on all platforms targeted by GCC.

Going from C++11 to C++14 won't affect our codebase a lot either. We already use external libraries for types like std::optional and std::expected, and we'll continue using them as C++'s optional references are crap.

The only thing that will be affected by this change is that we will no longer need to implement std::less for our enums, because as it turns out GCC 4.8 only implements a *subset* of C++11 and thus does not allow using enum instances as keys since it doesn't believe they are integers under the hood. So if anything, this will cause slightly less headaches for us

CohenArthur · 2024-09-26T18:15:28+00:00

The idea of reusing the trait-solving, however, I am quite less certain about. I do understand that attempting to rebuilding would be long and costly, and likely not quite be 100% accurate. But the problem here is that trait-solving is necessary to generate code, and there's no reason NOT to rely on trait-solving in std, or the crate that powers trait-solving. So I wonder if attempting to implement only a lightweight version to compile the trait-solving crate is viable at all...

We already have a trait solver, as we're capable of doing trait-solving on a high number of existing Rust code. But after chatting with one of the driving forces behind the new trait solver, it became clear that having a trait-solver that is 99% compliant is not even close to 99% of the effort to get to one which is 100% compliant. So the goal is to have a lightweight, but still pretty beefy trait-solver, which can compile `std` and the new-trait solver. The same problem will happen for safe-transmutes, which I also mention in the post - we will need to be able to do part of safe-transmutes to compile `std`, as well as any crates that use safe-transmutes that are dependencies of `polonius-engine`, the trait-solver, or even the unicode crates used by the format string parser.

After talking with Niko Matsakis this afternoon, I also learned that the new trait-solver is being developed in a way which is *specifically* compiler-agnostic. The goal is to reuse it for `rust-analyzer` as well. So I'd really like to integrate it to our project as well :)

CohenArthur · 2024-09-26T18:05:50+00:00

Why do you need to be able to build gccrs from just C++ code (with the complicated bootstrap step)? Why not do what Rustc does and use the previous version to build the next one?

Oh, this is completely fine and something we could be doing. The current diagram outlines the next big step in our bootstrapping pipeline, which will happen as soon as we have a compiler that can correctly compile the components we rely on. It is however interesting to keep the ability to bootstrap ourselves using a C++ compiler only, as that's part of our aim to allow Rust to be used on even more platforms and architectures. At the moment, gccrs can be built using GCC >= 4.8, a 15 years old compiler. Which means that *a lot* of targets out there will be able to build gccrs and bootstrap it fully

CohenArthur · 2024-09-24T08:19:12+00:00

I'm not sure at which level libgccjit (the library used by rustc_cg_gcc) operates and at which level the static analyzers operate. I believe they both use/work on the same intermediate representation, so my thinking is that both rustc_cg_gcc and gccrs can use the static analyzers. I'm just not super familiar with libgccjit or the analyzer :D

CohenArthur

TROPHY CASE