Call for help implementing an independent Rust frontend for GCC

The primary reason why I raised this topic i because of an experiment permitting rust modules to be added to the linux kernel

https://lwn.net/Articles/797828/

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.

Thus it is absolutely critical that GCC be capable not just of having rust capability but of having up to date rust capability.

However the second goal raised by this thread is just as important. The question is, which is easier? My feeling is that the incremental approach achieves both goals.

Unfortunately it does not support the full set of borrow capability nor has full error checking. As mentioned previously it would be months to years out of date.

3 Likes

For me makes more sense to make all linux kernel features be compiled with LLVM.

There is only one reason that happens, the gcc features that some modules use are incredibly undocumented

1 Like

Compiler monocultures, be it MSVC on Windows, GCC on Linux or AppleClang on macOS, have always caused problems historically. The latter experience suggests that an LLVM monoculture isn't better.

Therefore, compiler diversity is good, and it would be worthwhile to have both Linux building on LLVM and a Rust frontend to GCC, so that Linux + Rust can build via both GCC and LLVM.

13 Likes

The only company in the world to have the resources to pull that off was google. The source modifications are here and they are up to 600+ issues already

It is going to be a while before it's stable.

Also the fact that is is an active effort makes it all the more urgent to have rustlang capable of being gcc compatible.

1 Like

If this alternative Rust implementation is to be called "Rust" it will need to adhere to what the language team says the semantics and syntax of the language are. This includes:

  • not introducing new features in a stable fashion that do not exist in rustc
  • diverging in behavior from rustc except where rustc has bugs and when it comes to undefined-behavior.
  • declaring undefined behavior implementation defined in specific ways, including under certain flags.
14 Likes

Hi,
I've been talking about that in the GCC mailing list, and I'd like to add some points from this rather useful reply:

Another approach would be to build a gcc-based backend to the existing
rust compiler, as an alternative to its LLVM-based backend, rather than
a rust frontend to gcc. libgccjit (despite its name) has the ability
to generate ahead-of-time code (e.g. .o files), and has rust bindings,
and thus could be embedded inside rustc - in theory, at least. I'm the
maintainer of libgccjit. See this discussion:

Rust Front-End to GCC

My take from this is that if it was possible to link rustc to libgccjit, it wouldn't be necessary to output GIMPLE at all, since libgccjit is high level enough to abstract that away. One could, in theory, adapt the code that does the lowering of MIR to LLVM IR to call libgccjit instead, when requested.

Last but not least: I'd love to help with this, but I'm new to rustc and don't know where to go from here.

5 Likes

Another exception would be bugs in gcc-rust :slight_smile:

Doesn't this fall under "not introducing new features"?

Sure, just as in rustc, but they'll need to be treated as bugs and fixed :wink:

Yes, but I felt it needed to be mentioned explicitly.

2 Likes

I like the idea of using libgccjit as it is interesting.

However isn't the library self-described as "alpha quality" (in particular, with an unstable API)? Skimming through the wiki documentation, it seems unclear to me how one would perform e.g. cross-compilation using this library. I also don't know how that would work wrt. license since it is a GPL component. Would rustc be able to link to it?

Might be an interesting starting point nevertheless, I guess interested people could start by looking at librustc_codegen_llvm that was suggested by @cuviper above to see how a new backend would fit.

(I posted the thread to r/rust to give it more visibility.)

1 Like

<Insert standard I'm-not-a-lawyer speech here>

From a cursory examination of rustc's license, once the components
derived from LLVM were relicensed to Apache 2.0 (like the rest of
LLVM), there shouldn't be any license issues since all of the BSD,
MIT, and Apache 2.0 licenses are compatible with GPLv3; once rustc is
linked to gcc (via libgccjit or otherwise), the linked executable will
fall under the terms of the GPLv3 (as well as the other licenses).

Hi there :slight_smile:
I don't know a lot about compilers but I would love to see that happening. I had been thinking about that lately and having both multiple implementations of Rust and new supported platforms would really be great !
It's an effort I would love to help any way I can :+1:

The issue tha Jacob raised with libgccjit which may only be relevant to Kazan (long story, different compiler, SPIRV to LLVM) is that it only outputs to a .so dynamic library. LLVM's JIT writes to memory and thus the results may be executed directly.

I mentioned the rust libgccgit project, which exists already, in an earlier message. Found it via the gcc list.

we like reddit :slight_smile:

Good point. Which begs the question: is GIMPLE itself stable? That is, if we were to write GIMPLE directly instead of going through libgccjit, would we still have to keep up with breaking changes?

I'm also under this impression (though I'm not a lawyer either). I've dug up and found this GCC Runtime Library Exception but it doesn't seem to apply in this case.
It'd be wonderful if someone could take this question (of whether linking rustc to libgccjit would make it fall under the GPLv3) to the GCC folks to make sure, though. It'd be a shame not to be able to use a tool merely out of copyright issues.

While I see the benefits of independent implementations, it seems more feasible in the near future (in terms of how much work has to be done) to adapt the existing backend to generate code for GCC than to write a borrow checker for mrustc and mantain two separate implementations. But again, I'm new to rustc so please take this with a grain of salt.

Thank you for this.

I would anticipate that at least on major revisions of gcc that GIMPLE would be stable, probably more than that. Think about it: any noninteroperable changes cause a massive knock on effect across ADA, golang, d, c, c++, fortran, every frontend.

With rustlang's release cycle being 6 weeks and gcc major revisions being significantly longer, rustlang would be the primary stability decider, much less than GIMPLE.

If someone is already subscribed to the gcc list could they ask? Oh, it's you who's subscribed :slight_smile: yes, suggest asking on gcc list, ok?

You may have misunderstood the implications of what jacob wrote: it's already fine, is what he said. The licenses are compatible already at the binary level.

To whit: WITHOUT requiring relicensing, MIT expat does not PREVENT meeting the conditions and obligations of the GPL License (as applied to the whole work), therefore the obligations may be met, therefore quotes the licenses are compatible quotes, therefore relicensing does not need to be sought.

The nonEXPAT MIT on the other hand, and the BSD "Advertising" license, do prevent meeting the full obligations of the GPL, and consequently the combined work is quotes incompatible quotes. Luckily they are not being used here.

You're right, I've completely misunderstood that. Thanks for clearing it out.

Sorry, you're right, I should have asked there instead. But as you said rustlang's release cycles are much shorter so that's likely a non-issue.

It would be useful to know, maybe reduce the workload in between gcc major release cycles, I mean, I would kinda expect additions only rather than serious incompatible revisions to GIMPLE.

I'd love to see this happening.
This will make rust projects bootstrapable.
There are a lot of good people on the gcc/C side that are willing to work on this, hope some of the rust devs will help them on the rust side to make things easier and explain.

If you're the guy who couldn't build gccrs in the mailing list, it's because redbrain recently restarted the frontend altogether. Most of the current files in the repo are copied from the Go frontend and don't actually work; the rest are remnants of the old frontend and so are the cause of your linking errors. If you search back the commit tree far enough, you can get a working gccrs from before the rewrite begun.

I notice my post above re: requirement for independent compiler implementations has gathered a lot of likes. Thanks all, though I'm not sure it deserved it.

However I don't see that anyone answered the question posed there "So I wonder, who is it today that would require multiple compilers from multiple vendors?"

That discussion was looking at things from the point of view of correctness and verification, the ability to cross-check between compiler implementation. I actually have different motivation for multiple vendor Rust support:

That is all to do with longevity. I have worked on many code bases in all kind of language using all kind of tools, that became obsolete, unsupported, unavailable. Projects that died as a consequence or required huge investment to recreate in some other current language. There is a reason why we still see people using ancient PC's with Windows 98!

In the C/C++ world we are spoiled for choice. We have compilers from GCC, LLVM, Microsoft and a host of others. One can be confident that a C code base is not going to become unmaintainable any time soon.

I would like to have the same confidence in Rust. To that end Rust support in GCC, from MS and others, would be great to see.

Sadly I'm totally lacking in the skills required to contribute to such an effort.

3 Likes

MS will probably/hopefully be implementing Rust some time, since they are really pushing it for safety in their systems programming areas at the moment. They even advertise a senior Rust job at the moment!