GCC Rust Monthly Report #6 May 2021 | Hacker News Reader

GCC Rust Monthly Report #6 May 2021

thephilbert.io

106 pointsingve56 comments

The decision to implement an entirely new frontend is interesting, although regardless of that our experience with D is that having access to the GCC backend/s is very good for the language.

Hopefully they'll output trait information for GDB to use. Right now, gdb can't call any struct or trait methods e.g

    let string = String::from("something");
    // string.len() doesn't work in GDB

Debuggin rust still involves a lot of println! or debug!

https://github.com/rust-lang/rust/issues/33014

It is impressive work but I still think that using libgccjit as a backend is the right way forward since once it has been integrated it should be much less work to maintain.

https://github.com/antoyo/rustc_codegen_gcc

In case you hadn’t read the article making the case for this: https://shnatsel.medium.com/the-simpler-alternative-to-gcc-r...

I thought it was pretty interesting, though based on the reddit comments (https://reddit.com/r/rust/comments/noby1t/the_simpler_altern...) the main concern seems to be if a second Rust is implemented without a spec, it could lead to subtle incompatibilities?

It is also very antagonistic. It's not an evenhanded exploration of the tradeoffs of two approaches, it's pretty much just talking trash. Disappointing.

I disagree that it's "just talking trash". Sure, I agree the tone of the article is overly harsh on the gcc-rs project, but it does raise some solid points that, for the stated goals of the project, the approach appear suboptimal.

Every time gcc-rs comes up, the discussion always devolves to a "but there's rustc_codegen_gcc, why bother rewriting the language in C++", and I have yet to see a compelling argument why GCC-RS is indeed a superior solution, despite the many downsides.

I think the answer is that it isn't necessarily a better solution, but the people with the necessary knowledge to make a gcc frontend or backend happen tend to be more familiar with C++, and so GCC-rs is actually the path of least resistance?

As I said below, one example of a significant advantage is not needing any sort of Rust compiler. It’s not one to me but it is to some.

I am not saying that the project is above criticism, or that there are no downsides to its approach, but this article isn’t interested in dispassionate engineering analysis.

Yep, the author was very clear from the beginning that he didn't like the idea of gcc-rs and wasn't really willing to compare both approaches on the same level.

I personally think that's a good thing that multiple approaches to the problem exist and in the end, the better one will hopefully be adopted by the community.

> in the end, the better one will hopefully be adopted by the community.

Or both. I mean, is there anything wrong with having multiple implementations of a language?

They may each be better for different reasons.

The Rust people don't believe in specs. (I guess the reasoning is that if you ignore the problem is just goes away?)

Anyways, their loss, not mine.

Until Rust gets a real standard it will forever be a toy language. For many (most?) people in the systems programming sphere (including me) the lack of a standard is the #1 impediment to using Rust.

The Rust people firmly believe in specs and are working on one (most of the activity is currently in Ferrocene). On the other hand, they fully appreciate that writing a good spec is very hard and takes time, while a bad spec can do lots of damage to the ecosystem.

I've been expecting some kind of announcement from the lang team saying something about how the third party Ferrocene / sealed Rust project fits in with the official project and its documentation.

Do you know if there's been one that I've missed?

Some of the work involved in producing a specification will involve making decisions about corner cases which aren't currently nailed down. What I'm wondering is whether the Ferrocene people are going to be effectively authorised to make those decisions.

I mean, it’s always been there ever since it was announced. See https://ferrous-systems.com/blog/sealed-rust-the-plan/ which talks about working with upstream, and the thanks to two Lang team members at the end.

There is, to my mind, a significant difference between a blog post from the lang team and a blog post from Ferrous systems which thanks the lang team for their feedback.

Do you know if Ferrocene will be closed source or proprietary in any way? This is very worrying:

https://ferrous-systems.com/blog/sealed-rust-the-pitch/#fund...

And clashes with the entire development of the Rust language so far.

The Rust foundation should be the organization heading the standardization efforts, not some shady GmbH.

But looking at https://foundation.rust-lang.org/ I see a content-devoid site that holds nothing but passive-aggressive demands for money.

That's about as far away from "firmly believing" as possible given the circumstance.

The Foundation is a recent development. The efforts by Ferrous to make Rust more suitable for safety-critical work predate the creation of the Foundation by quite some time; there was quite a bit of work done under the "sealed Rust" banner before that was rebranded as Ferrocene.

Good specs don't emerge from thin air (though I suspect that many bad specs emerge through spontaneous generation), and the people who work on them deserve to be funded. While I'm not claiming the process the Rust community has is perfect, it is explicitly designed to be sustainable, and I think it's right to be proud of the collaboration between different companies, large and small, and also academia; Ralf Jung's work in particular is foundational and he well earned his recent PhD for it.

No offense, but your explanation reads like something a politician would produce when trying to explain why that airport missed deadlines while over budget and all that remains in abundance is a bunch of shell companies.

Do you have some sort of an SLA with Rust, stating that all of this work should already have been completed?

It's a relatively new project, and will take time to catch up to existing languages in many areas.

Neither C or C++ started with a standard.

The head of that “shady GmbH” is on the Core team, and is one of the Core Team’s board representatives for the Foundation.

Regardless, it is a misunderstanding of Rust’s governance to suggest that the Foundation would lead a standardization effort; the Language Team, part of the Project, not the Foundation, is in charge of the definition of the language.

Is that project kosher wrt to the GPL? Is libgccjit covered under the GCC exception?

Would someone kindly ELI5 what is GCC Rust ?

A third implementation of the rust compiler.

The official compiler has an LLVM backend. GNU also wants to provide rust, and is adding a rust front to their gcc compiler.

These monthly reports document the progress until the gcc compiler reaches feature parity with the LLVM-based compiler

> A third implementation of the rust compiler.

What is the second rust compiler?

I am assuming they're talking about https://github.com/thepowersgang/mrustc

Others claim mrustc is the second, but has anyone actually tried to use it? the readme does not inspire too much confidence, and looks to (currently) be a C transpiler:

"mrustc's primary goal is bootstrapping rustc, and as such it tends to assume that the code it's compiling is valid (and any errors in the generated code are mrustc bugs). Code generation is done by emitting a high-level assembly (currently very ugly C, but LLVM/cretone/GIMPLE/... could work) and getting an external tool (i.e. gcc) to do the heavy-lifting of optimising and machine code generation."

At least it can be used to bootstrap the actual rust compiler. It's a bit crazy to me how popular this language appears to be, but doesn't have a proper second compiler yet.

mrustc[0] I think.

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

I always thought Rust and other PLs generate LLVM IR and leave the optimizations to LLVM while GCC has something more complex to deal with, doesnt it make things much complicated ?

This has largely been true for Rust, however, there are some optimizations that the compiler does before generating LLVM IR.

* Compiler docs: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html

* Working Group: https://rust-lang.github.io/compiler-team/working-groups/mir...

* Example of one such optimization, "constant propagation" https://blog.rust-lang.org/inside-rust/2019/12/02/const-prop...

GCC and LLVM have very similar structures, as do all compilers. LLVM IR is only special because it has a defined serialization.

GCC has an IR called GIMPLE that’s fine.

It is complicated, but GCC has more target platforms.

And generates faster code depending on which benchmarks matter to you

Using GCC for Rust backend compilation instead of LLVM.

No, this is writing a new frontend for compiling Rust which uses GCC as a backend.

Was it actually done tabulā rasā?, why?

Certainly quite a bit of rustc could be cannibalized? Surely the parsing, type, and borrow checking stage or perhaps all the way to the m.i.r. could have been shared.

There is a different project that grafts the existing rustc frontend to the gcc backend: rustc_codegen_gcc. The existence of both projects is currently very contentious, as there are concerns about duplicated effort and possible fragmentation of the community. Some of the goals, like the ability to target more architectures, are equally supported by both projects, but for other goals (mostly more organizational and less technical, to my ears) they're pretty different.

Philosophically, I think the view is that two independent implementations will give the language more long term stability by helping it avoid the trap of a single implementation, with its bugs, being the definitive version of the language.

On the practical level, rustc is written in rust and self-hosting, so reusing code from it in gcc would mean that you needed a rust compiler as well as a c compiler to compile gcc.

Also, rustc and gcc have incompatible licenses.

I am not a licensing lawyer, but the license for rustc (and its standard library, and a great many infrastructural crates in the ecosystem) is dual MIT + Apache 2, which was explicitly chosen so that it would be compatible with both GPL v2 and GPL v3.

I think that the biggest barrier to having GCC use the rustc frontend isn't technical, it's the requirement of copyright assignment to the FSF.

There is no such requirement to develop one's own frontend for the GCC, but there sometimes is to be part of the GNU project.

You can always take GNU licensed code and build what you want as long as you comply with the license, but to be part of the GCC release that copyright assignment requirement exists.

Do you know whether the GCC Ada, Fortran, Go, D and Java frontends also assign full copyright to the FSF? Are the copyright of all dependencies likewise assigned to them?

That wasn't a problem when GCC was a requirement to keep free beer UNIX alive, how quickly people forget.

It is a problem when trying to bring code from an existing codebase that has no such copyright assignment clauses. Bringing the rustc frontend code into gcc would be unlikely because getting a copyright release to GNU from everyone that contributed to rustc would be unlikely.

> On the practical level, rustc is written in rust and self-hosting, so reusing code from it in gcc would mean that you needed a rust compiler as well as a c compiler to compile gcc.

I see, they want a full Rust implementation written in C++ rather than in Rust?

Part of the point is that you won’t need a Rust compiler to compile this. If you did that, you would.

There is another project pursuing that approach. Both are valid strategies with different pros and cons.

Didn't that recent critique of this project say that they've already imported some Rust code, so that wouldn't be true.

I don’t know what you’re referring to, exactly. I’m pretty sure you’re talking about the post linked above but I don’t remember reading that in it. It’s possible I missed it!

I believe gcc-rs has a dependency on Polonius, the new(ish) experimental Rust borrow checker.

Gotcha, thanks. I wonder about the details here; you could imagine that as either a temporary step until things are further along, or possibly a thing only introduced later in the bootstrap process after you’ve built a stage1 compiler, which you could use to build this without an external rustc.

Polonius is an awesome name for a borrow checker! Just hope there’s a —no-verbose flag.

Great work! Does any know if this new frontend will improve rust compilation time?

I usually hear that LLVM is a bit faster than gcc in compilation time (and a bit slower in program efficiency).

Will GCC Rust reuse the Rust `std`, the standard library?

I just hope they would add someway to hide warnings from dependent libraries during compilation. It's a really annoying part of rust compilation when developing prototypes.

Hm, this should already be the case, with cargo passing cap-lints. Maybe you should file a bug!

Reply on news.ycombinator.com