An update on the development of gccrs (LWN.net)

Ready to give LWN a try?

With a subscription to LWN, you can stay up to date with what’s happening in the Linux and free software community and take advantage of site features available only to subscribers. We are happy to offer you a free trial subscriptionno credit card required so you can see for yourself. Please join us!

A concern that has often been raised about the Rust language is that there is only one compiler for it. That makes it difficult to say what the standard version of the language is and limits the architectures that Rust code can target to those that the available compiler supports. Adding a Rust frontend to GCC would do a lot to alleviate these concerns; during GNU Tools Cauldron 2024, Pierre-Emmanuel Patry provided an update on the state of that work and what its objectives are.

The GCC frontend is called “gccrs”; the trademark rules surrounding the language prevent it from being called a Rust compiler. Since the project restarted in 2019, Patry focused on release 1.49 of the language, which came out in 2020. It has been included in GCC since GCC 14, although that release did not include the gccrs documentation.

At the 2023 GNU Tools Cauldron, Patry had said that the project had over 800 commits in the repository that needed to be transported upstream to the GCC mainline – a significant pile of work. This year that number has been reduced to forty – and that is new work, not leftovers from the previous year. So some progress has been made. The goal had been to implement changes every two weeks, but that turned out to be too much work; they’re still aiming to get their code upstream as quickly as possible, although they’ve backed off on that specific goal.

This past year, the development of gccrs was aided by three Google Summer of Code (GSoC) interns. One of them (Jasmine Tang) worked on support for inline assembly code, a feature that the Rust-for-Linux project needs; most of the frontend work for that is now done. Inline editing in Rust looks like this:

    unsafe {
        asm!("assembly code here", "other info")
    };

While the frontend work was being done, there were some issues getting the assembly code intact through the later compilation stages. These issues have been resolved, but several details remain to be resolved.

The second GSoC student (Muhammad Mahad) worked on a test suite adapter, with the goal of helping gccrs pass the Rust test suite. There is an impedance mismatch to work here; GCC uses DejaGnu for its tests, so some sort of conversion from Rust’s tests is needed. The last GSoC student (Kushal Pal) worked on checking loans in the GCC intermediate view and getting the correct error messages for users.

Looking ahead to the upcoming GCC 15 release, Patry said the primary focus is on implementing features needed to compile kernel code with gccrs. The main task there is to get to a point where gccrs can compile the Rust core library, which is proving to be no easy task. The developers thought they had implemented enough to do that, but were surprised by many issues that needed to be resolved. The Rust project’s habit of using experimental features in the core library doesn’t help.

Those issues are being worked on, Patry said, but even if they work, the compiler is currently quite slow. However, that’s an issue we’ll have to worry about later, once the functionality and correctness work is complete and the core library is built.

To conclude the longer-term goals, Patry began building the core library again, but this time without making any changes to the library itself. The developers would like to catch up with the 1.78 release currently used by Rust for Linux. That’s not as big a jump as you might think, he said; many of the 1.78 features were experimental long before and have already been implemented in gccrs. In addition, he said, the project will eventually focus on building the std library and, one day, work on catching up with the rustc compiler.

The impression this session leaves is that the gccrs developers are working hard to fill the gap in the second compiler for Rust, but there are far too few of them. This is an important project that should receive significant industry support, but for the most part it doesn’t. Unless more industry players continue this work, Rust may be doomed to remain a single compiler language for a long time.

---