There was a thread posted on the rust forum a while back that laid out the goals of this project [0]:<p>> A friend of mine (Luke) has been talking about the need for a Rust frontend for GCC to allow Rust to replace C in more places, such as system software. To allow some types of safety-critical software to be written in Rust, the GCC frontend would need to be an independent implementation of Rust, since the relevant specs require multiple independent implementations (so just attaching GCC as a new backend for rustc wouldn't work).<p>Luke:<p>> The goal is for the GNU Compiler Collection to have a peer level front end to the gfortran frontend, gcc frontend, g++ frontend and all other frontends.<p>> The goal is definitely not to have a compiler written in rust that compiles rust code [edit: unless there is an acceptable bootstrap process, and the final compiler produces GNU assembly output that compiles with GNU gas]<p>> The goal is definitely not to have a hard critical dependence on LLVM.<p>> The goal is to have code added, written in c, to the GNU Compiler Collection, which may be found here <a href="https://gcc.gnu.org" rel="nofollow">https://gcc.gnu.org</a> 20 such that developers who are used to gcc may compile rust programs and link them against object files using binutils ld.<p>> The primary reason why I raised this topic is because of an experiment permitting rust modules to be added to the linux kernel: <a href="https://lwn.net/Articles/797828" rel="nofollow">https://lwn.net/Articles/797828</a><p>> What that effectively means if that takes off is that the GNU Compiler Collection, which would be incapable of compiling that code, would be relegated to a second class citizen for the purposes of compiling the largest software project on the planet: the linux kernel.<p>> Thus it is absolutely critical that GCC be capable not just of having rust capability but of having up to date rust capability.<p>0: <a href="https://users.rust-lang.org/t/call-for-help-implementing-an-independent-rust-frontend-for-gcc/32163" rel="nofollow">https://users.rust-lang.org/t/call-for-help-implementing-an-...</a>
There is another project for implementing a GCC backend for Rust which instead uses the libgccjit API.<p><a href="https://github.com/antoyo/rustc_codegen_gcc" rel="nofollow">https://github.com/antoyo/rustc_codegen_gcc</a>
Is a great deal of actual <i>Rust</i> behavior not fairly intimately tied to <i>LLVM</i>? As far as I know it leaks various <i>LLVM</i> details and much of the documentation about various functions documents them as being little more than a thin wrapper to various <i>LLVM</i> internals.
I suspect it's too late, but one lesson that can be learned from D is that having one frontend implementation with multiple backend glue layers is much more convenient than having one in D and one in C++ (I believe Iain Buclaw is in the process of moving the D frontend in gcc to use the proper D one as it's been lagging behind)
The timeline looks rather ambitious <a href="https://github.com/Rust-GCC/gccrs/milestones" rel="nofollow">https://github.com/Rust-GCC/gccrs/milestones</a>
I'm not sure if what I'm asking makes sense, but since it's written for a new backend, would the authors have to bootstrap it using a different toolchain? I guess what I'm asking is, could they use the LLVM Rust to build the GCC frontend or do they have to start all over with a different base language to get a first working version of a rust compiler?
A bit off topic, I hope someday GCC's build system gets overhauled. A huge advantage of LLVM is that it is quite easier to rebuild the runtime libraries without rebuilding the compiler. With GCC that's a pain, unless one takes the time to re-package GCC very carefully like <a href="https://github.com/richfelker/musl-cross-make" rel="nofollow">https://github.com/richfelker/musl-cross-make</a> and <a href="https://exherbo.org/" rel="nofollow">https://exherbo.org/</a>.<p>Maybe getting some new GCC devs in there with projects like this would help with that?
Don't try to compile this with `make -j` - I tried, and my system ran out of ram and swap and started OOM killing things. I have 16 threads and 32gb of ram.<p>Running `make -j4` seems safe thus far.
Ecstatic to see this. Once this stabilizes then I can switch my shop to rust and not look back. If I find some spare time I will absolutely try to find a way to contribute.
Does this mean that compilation target currently supported by GCC would now allow rust to target that architecture? Specifically I'm thinking of PPC cores with the VLE extension, which LLVM does not support (as far as I'm aware).
from the readme :<p>> The developers of the project are keen “Rustaceans” with a desire to give back to the Rust community and to learn what GCC is capable of when it comes to a modern language.<p>So what's the answer right now ? How does GCC measures "against" rust ?
What I really hope is that the Rust community doesn’t go out of its way to make this easier. Communicate and let value come back but there’s an significant amount of value in keeping a single backend relies on. CPython has done the Python community a lot of good by keeping one official compiler/tool chain (despite the great work done by projects like JPython/PyPy).<p>The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “). The value would be if the majority of bugs/features are in the shared frontend.<p>This project though seems like a parallel implementation of Rust. That’s valuable for the community and inevitable as a part of successful growth. I don’t believe it’s beneficial to the community though if this grows beyond a toy, niche project.