[HN Gopher] GCC Rust Monthly Report #6 May 2021
___________________________________________________________________
GCC Rust Monthly Report #6 May 2021
Author : ingve
Score : 101 points
Date : 2021-05-31 13:37 UTC (9 hours ago)
(HTM) web link (thephilbert.io)
(TXT) w3m dump (thephilbert.io)
| pjerem wrote:
| Would someone kindly ELI5 what is GCC Rust ?
| gostsamo wrote:
| Using GCC for Rust backend compilation instead of LLVM.
| jeltz wrote:
| No, this is writing a new frontend for compiling Rust which
| uses GCC as a backend.
| Blikkentrekker wrote:
| 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.
| steveklabnik wrote:
| 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.
| IshKebab wrote:
| Didn't that recent critique of this project say that
| they've already imported some Rust code, so that wouldn't
| be true.
| steveklabnik wrote:
| 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!
| raphlinus wrote:
| I believe gcc-rs has a dependency on Polonius, the
| new(ish) experimental Rust borrow checker.
| qzw wrote:
| Polonius is an awesome name for a borrow checker! Just
| hope there's a --no-verbose flag.
| steveklabnik wrote:
| 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.
| raphlinus wrote:
| 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.
| karatinversion wrote:
| 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.
| raphlinus wrote:
| 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.
| estebank wrote:
| 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.
| pjmlp wrote:
| That wasn't a problem when GCC was a requirement to keep
| free beer UNIX alive, how quickly people forget.
| hyperman1 wrote:
| 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
| up6w6 wrote:
| 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
| ?
| astrange wrote:
| 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.
| steveklabnik wrote:
| 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...
| gostsamo wrote:
| It is complicated, but GCC has more target platforms.
| mhh__ wrote:
| And generates faster code depending on which benchmarks
| matter to you
| sampo wrote:
| > A third implementation of the rust compiler.
|
| What is the second rust compiler?
| shipp02 wrote:
| mrustc[0] I think.
|
| [0](https://github.com/thepowersgang/mrustc/)
| [deleted]
| [deleted]
| modshatereality wrote:
| 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.
| steveklabnik wrote:
| I am assuming they're talking about
| https://github.com/thepowersgang/mrustc
| jeltz wrote:
| 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
| mhh__ wrote:
| Is that project kosher wrt to the GPL? Is libgccjit covered
| under the GCC exception?
| [deleted]
| faitswulff wrote:
| 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?
| steveklabnik wrote:
| 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.
| roblabla wrote:
| 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?
| steveklabnik wrote:
| 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.
| cbmuser wrote:
| 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.
| otabdeveloper4 wrote:
| 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.
| raphlinus wrote:
| 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.
| otabdeveloper4 wrote:
| 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.
| steveklabnik wrote:
| 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.
| raphlinus wrote:
| 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.
| otabdeveloper4 wrote:
| 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.
| mjw1007 wrote:
| 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.
| steveklabnik wrote:
| 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.
| mjw1007 wrote:
| 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.
| kzrdude wrote:
| Will GCC Rust reuse the Rust `std`, the standard library?
| option_greek wrote:
| 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.
| steveklabnik wrote:
| Hm, this should already be the case, with cargo passing cap-
| lints. Maybe you should file a bug!
| mhh__ wrote:
| 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.
| Popegaf wrote:
| 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
| longstation wrote:
| Great work! Does any know if this new frontend will improve rust
| compilation time?
| up6w6 wrote:
| I usually hear that LLVM is a bit faster than gcc in
| compilation time (and a bit slower in program efficiency).
___________________________________________________________________
(page generated 2021-05-31 23:02 UTC)