GCC Rust: GCC Front-End for Rust

by varbhat • 6 years ago

312 173 6 years ago

ognarb• 6 years ago

This is very cool, maybe this could push the rust community to have a formal specification and a stable ABI in the future.

steveklabnik20• 6 years ago

The work on a spec is already going as fast as it reasonably can be.

A stable ABI is unclear.

rectang• 6 years ago

Glad you're going slow on the stable ABI and resisting the pressure to put out something half-baked. The C++ ABI is horribly fragile and complex. Unless the pitfalls of C++ can be avoided, making no ABI promises is better.

Blikkentrekker6• 6 years ago

Does it not already have them if the programmer elect for it by choosing `repr(C)`, or is there more to it than that?

wiz21c• 6 years ago

from the readme :

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.

So what's the answer right now ? How does GCC measures "against" rust ?

bonzini2• 6 years ago

Front-end–independent optimizations are still slightly better in GCC than in LLVM.

moonchild• 6 years ago

I wouldn't say 'better'. Certainly, they're different. GCC does better in some ways, but worse in others. Somewhat notably, GCC doesn't do as good of a job at register allocation on some RISC architectures.

pjmlp12• 6 years ago

Given the amount of existing frontends for GCC, even if not included in the main branch, not sure what they imply as modern.

Ada, D, Go, Modula-3, Modula-2, C++20

vips7L• 6 years ago

RIP gcj.

yorwba• 6 years ago

The timeline looks rather ambitious https://github.com/Rust-GCC/gccrs/milestones

unanswered3• 6 years ago

It also looks rather incomplete. Are they not planning on implementing borrowck? If chalk/polonius were ready and had a C API the roadmap would begin to make sense.

Nullabillity• 6 years ago

Makes sense to me. As mrustc[0] mentions, implementing validation in a secondary compiler is much less important, because you can always just run the reference implementation as a glorified linter in the meantime.

[0] https://github.com/thepowersgang/mrustc

faitswulff3• 6 years ago

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?

gumby• 6 years ago

It's not written in rust; gcc is written in c. There is no bootstrapping involved.

faitswulff3• 6 years ago

Do gcc languages - even low level ones - remain written in c?

Narishma• 6 years ago

C++ but yes.

NieDzejkob• 6 years ago

GCC is no longer written in C, but in C++. They switched after GCC 4.7.

singron• 6 years ago

As far as I can tell, this is written in C++ like the rest of GCC, so they don't need a rust compiler to bootstrap.

faitswulff3• 6 years ago

I see, so it’s written in C++. Would it remain that way, though? AFAIK the LLVM Rust is, itself, written in Rust, right? I imagine that it would be a goal to do the same for gcc.

moltonel3x2• 6 years ago

Looking forward to the day when gcc gains a C++ frontend written in Rust, to enable bootstraping gcc from a rust compiler :)

oconnor6632• 6 years ago

The LLVM-based Rust compiler uses a lot of unstable/nightly-only Rust features internally. So even if this project got to the point where it could compile all stable Rust programs, I think it would take quite a bit more work than that to be able to compile `rustc` itself. (It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?)

steveklabnik20• 6 years ago

It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?

It might. There are at least two major things off the top of my head, regarding libstd:

1. specialization is needed for performance around String and &str

2. const generics are needed to support some trait implementations

We currently allow some stuff like this to leak through, in a sense, when we're sure that we're actually going to be making things stable someday. An alternative compiler could patch out 1, and accept slower code, but 2 would require way more effort.

There has been some discussion about trying to remove unstable features from the compiler itself, specifically to make it easier to contribute to, but it unlikely that it will be completely removed from the current implementation of libstd for some time.

cbmuser• 6 years ago

Isn‘t mrustc already able to compile rustc?

rcxdude• 6 years ago

If it was written in rust, there's no reason they couldn't use LLVM rust to start development until it became self-hosting. (Same as you can develop a self-hosting C compiler by starting with gcc)

vlovich1232• 6 years ago

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

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.

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.

thesuperbigfrog2• 6 years ago

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

No. The correct way is to create a Rust language specification that describes what the correct behavior is.

Then whether LLVM, GCC, or something else is used does not matter. There won't be one implementation with defacto behavior, there will be multiple implementations that follow the spec.

This is the way mature languages work.

not2b2• 6 years ago

It doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.

Blikkentrekker6• 6 years ago

Such standardized specifications are typically a response to many divergent implementations existing and a need to standardize a common ground between them.

Few languages find such specification before that time.

Python also lacks it despite some competing implementations, since none actually diverge enough from CPython.

not2b2• 6 years ago

Strongly disagree. It will only benefit the language to have more than one quality implementation. C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better. To be fair, it will take a while before the GCC Rust front end is competitive, but for some purposes it doesn't have to be, like bootstrapping.

If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down. But that problem can be addressed with editions: at some point, if the project is a success, the gcc front end will be a feature-complete version of some Rust edition, plus enough extra features to build an older version of the Rust compiler. At that point, you have a better solution to the bootstrapping problem (how to get a Rust compiler when you only have a C compiler and you want to build everything from source and not trust some binary you download from somewhere).

jcelerier• 6 years ago

C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better.

yet rust has a single implementation and by some metrics does better than both.

turminal3• 6 years ago

If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down

This has to happen at some point anyway otherwise we'll just get another C++. And I don't think Rust would benefit from that. New languages are designed to fix problems with the old ones, not to replicate them after all.

I just hope the designers will choose that point wisely.

JoshTriplett• 6 years ago

It will only benefit the language to have more than one quality implementation.

As long as "quality implementation" means "implements the entire Rust language and not a subset".

Because otherwise, people will start getting requests to avoid using features that the non-standard Rust toolchain doesn't support.

steveklabnik20• 6 years ago

The general sentiment of the community and leadership is that this project is a good thing, so you are unlikely to get your wish.

turminal3• 6 years ago

Having multiple independent implementations (and a spec) is key to being a serious portable systems language, a claim that Rust already makes. I believe it's too early for that, but sincerely wish them success achieving those goals in the future and having multiple implementations is certainly going to help here.

eg “oh this problem comes up with GCC so use the LLVM backend “

The point of having multiple implementations is making the language independent of the underlying system. A programming language is an abstraction. The only way to test whether an abstraction is a good one is trying out how well it abstracts away various underlying systems. That's why Rust needs ports to various architectures, OSes and compiler backends. Having GCC as a backend counts double here, because you get a few new target architectures for free with the port not just a new backend.

It's of course much different with Python but I can still clearly see how having an implementation defining a standard hurts the language.

simias• 6 years ago

Remember that Rust is supposed to be an alternative to C or C++, where the "this problem comes up with GCC so use the LLVM backend" is really rare and generally a sign of a bad codebase (exceptions being things like the Linux kernel that are so huge, optimized and domain-specific that they often end up relying on compiler dialects).

One exception to this is Visual Studio's toolchain but let's not talk about Visual Studio's toolchain on a weekend...

pjmlp12• 6 years ago

Yeah, when one forgets that there are more C and C++ compilers out there in the industry than just the pair that the FOSS community cares about.

dleslie• 6 years ago

This is excellent; there's embedded targets that LLVM doesn't officially support and GCC does.

mhh__3• 6 years ago

GCC is straight up faster in quite a few benchmarks (it's basically neck and neck in most benchmarks, and you should try both if it matters).

GCC is also roughly even in compilation speed now https://www.phoronix.com/scan.php?page=news_item&px=GCC-Fast...

LLVM is much easier to work with internally but GCC is a seriously good compiler even now.

Blikkentrekker6• 6 years ago

Is a great deal of actual Rust behavior not fairly intimately tied to LLVM? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.

chrisseaton2• 6 years ago

I'd find that very surprising and interesting - I can't imagine which semantics could leak from LLVM into a language specification. Can you give some examples?

Blikkentrekker6• 6 years ago

For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction

I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM's using of signed integers here is apparently nonstandard and what lead to Rust's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-alloc.html

monocasa• 6 years ago

I don't think much of the stable functionality exposes llvm internals. Part of stabilizing is removing the llvm leaks into the language.

dagmx• 6 years ago

Potentially but there are alternative backends like cranelift so it's unlikely anything major is tied to just LLVM anymore

steveklabnik20• 6 years ago

IMHO, "great deal" is overemphasizing it. There are some things, yes, but they are mostly smaller, more niche details that are even probably things we'd choose ourselves in many cases.

That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.

masklinn2• 6 years ago

Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.

I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.

anticensor2• 6 years ago

They missed the opprtunity to name it as grust.

codetrotter3• 6 years ago

Gust of wind

anticensor2• 6 years ago

grust, not gust

mhh__3• 6 years ago

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)

steveklabnik20• 6 years ago

There are pros to that approach, but also cons. The major con is that keeping the rustc frontend would make an existing Rust compiler be a requirement, and not having that makes bootstrapping easier, which is a major pro.

This (among other things) was debated a lot.

mhh__3• 6 years ago

The major con

A major con of not sharing is not having a backend at all. It's a lot of work to keep up with a moving target

jeltz• 6 years ago

There is another project for implementing a GCC backend for Rust which instead uses the libgccjit API.

https://github.com/antoyo/rustc_codegen_gcc

ibraheemdev• 6 years ago

There was a thread posted on the rust forum a while back that laid out the goals of this project [0]:

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

Luke:

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.
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]
The goal is definitely not to have a hard critical dependence on LLVM.
The goal is to have code added, written in c, to the GNU Compiler Collection, which may be found here https://gcc.gnu.org 20 such that developers who are used to gcc may compile rust programs and link them against object files using binutils ld.
The primary reason why I raised this topic is 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.

0: https://users.rust-lang.org/t/call-for-help-implementing-an-...

ncmncm3• 6 years ago

It would be a grave error to have coded the Rust frontend to Gcc in C (or, as written above, "in c"). Gcc is now a C++ codebase, and new components should be coded in modern C++, for better productivity, performance, safety, and maintainability.

(You might prefer not to consider modern C++ more productive, performant, safe, and maintainable than C (and reflexively downvote), but the statement remains true: Gcc did transition to C++, for reasons. And, all the improvements that have kept Gcc competitive with Clang were done, since. And, Clang and LLVM are also coded in C++, also for reasons.)

djur• 6 years ago

gccrs is written in C++, so no worries there.

anfilt2• 6 years ago

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust.

For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs.

C++ is going to be harder to boot strap than either Rust core or C when trying to build a compiler for a new system/platform. C probably is the easiest bootstrap of the 3.

Rust and C are generally more performant than C++ code. Also in the realm of low end micro controllers C code tends to have the smallest binary image size.

In C++ if you need to interact with other languages a lot times your stuck to the C abi which which forces you to avoid a lot C++ features/constructs. As for rust its not an object orientated language and its unsafe blocks generally make it easier to at least keep rust code idiomatic.

C++ is also a massive kitchen sink of a language with many ways to hide gotchas. Probably the worst thing in C is its null terminated strings but C++ also suffers from that. C is simple, and rust has at least so far made good design choices for the most part.

There also choices in the C++ language that are even part of the standard library that seemed like a good idea but with hind sight are not that great of idea. For example operator overloading.

Although we are talking a GCC front end so I would be surprised to see both C and C++.

Ericson2314• 6 years ago

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 https://github.com/richfelker/musl-cross-make and https://exherbo.org/.

Maybe getting some new GCC devs in there with projects like this would help with that?

potatochup2• 6 years ago

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

volta874• 6 years ago

llvm does support ppc64le cores with VSX extension; if thats what you mean

in fact, IBM uses LLVM proper as its own compiler backend for its ppc processors

potatochup2• 6 years ago

The VLE I'm talking about is this: https://www.st.com/resource/en/user_manual/cd00161395-variab...

This may be a vendor-specific extension though?

BlackFingolfin• 6 years ago

Sorry for the nitpick, but I find the title rather confusing; shouldn't it rather be "Rust front-end for GCC"?

pirocks• 6 years ago

You could make the argument that, that would be a frontend written in rust.

piinbinary2• 6 years ago

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.

Running `make -j4` seems safe thus far.

tele_ski• 6 years ago

did you try make -j16 since you have 16 cores? -j with no number means spawn as many parallel jobs as possible which could be hundreds or thousands depending on the project, I learned this the hard way a while ago myself when I used $(nproc) incorrectly on a project, got the same OOM/swapping death spiral!

piinbinary2• 6 years ago

I incorrectly assumed that `-j` and `-j$(nproc)` would do the same thing. TIL!

jjnoakes3• 6 years ago

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.

kzrdude• 6 years ago

Do you mean that you will use this, or just have the alt implementation as a checkbox item? Because - I'm just guessing of course - for this to be a mature alternative compiler we might be looking at 5, 10 years in the future, or never. Just being realistic, things take time to grow (and it's also uncertain how they can ever be able to keep pace with the rapidly developing Rust project).

With all this said, I would love for them to succeed, for multiple reasons. Including <3 GPL.

jjnoakes3• 6 years ago

I mean that I'd use it. If it takes a while then maybe I can get by with mrustc for a bit (haven't tried yet) but the net of it is that I need to support systems which llvm does not, which has kept me from using rust in product thus far.

stevefan1999• 6 years ago

This is the very first step to getting Rust into Linux kernel. I liked that.

steveklabnik20• 6 years ago

It is not required for getting Rust into Linux.

GCC Rust: GCC Front-End for Rust

Related Stories