23 ms·

GCC Rust Approved by GCC Steering Committee

436 points by edelsohn 4y ago

maxyurk 4y ago
a naive question - would it be faster than the "regular" rust compiler?
- cogman10 4y ago
  I can't seem to find any benchmarks around it. I'm assuming as this gets further integrated into GCC, you'll start to see those crop up.
fbanon 4y ago
- klez 4y ago
  Care to elaborate?
  - kangalioo 4y ago
    Maybe referring to the fact that GCCRS duplicates a ton of effort by reimplementing the frontend (parser, borrow checker, error messages etc.) for questionable benefit since you could keep the existing frontend and just swap out the LLVM backend for GCC (as done by the rustc_codegen_gcc project).
    - wtetzner 4y ago
      This ignores the benefits of having multiple implementations, e.g. you can use places where two implementations disagree with each other to track down bugs in one or both of them.
outside1234 4y ago
Why would someone want this? (Honest question)
- dleslie 4y ago
  Gcc has more stable hardware targets than llvm, for starters.
  - pavon 4y ago
    Note that there is a separate project to use the GCC backend with the Rustc frontend. At least in the short-term, that project will be the better approach to providing the benefits of more hardware support, since it will be more complete and compatible with the rustc/llvm compiler. The main benefit of a GCC front-end is to move Rust beyond a single vendor, and shakeout ambiguities in the (informal) language specification.
- mistrial9 4y ago
  alternate architectures; plurality
  - nickitolas 4y ago
    Isn't this already addressed by the GCC backend for rustc? (Via libgccjit)
- twic 4y ago
  Multiple implementations of a standard help shine light into dark corners.
  - pca006132 4y ago
    Indeed, but I think they should first create a standard?
    - rob74 4y ago
      If not a standard, then at least a specification. This discussion is from 2020, so I'm not sure if it's still up to date: https://users.rust-lang.org/t/where-is-the-rust-language-specification/42047 https://users.rust-lang.org/t/where-is-the-rust-language-spe... "For the most part though, rustc itself is the spec" - so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? And try to keep up with all the changes which will inevitably happen in the LLVM frontend while you are implementing the GCC frontend?
dleslie 4y ago
This is great! Gcc support opens up more platforms, more targets, and the opportunity to more easily integrate with the various common embedded toolchains that are built around gcc. And it's free software, for those that care, this matters.
- mistrial9 4y ago
  > free software it seems like this term is misunderstood in English to mean "no money" .. perhaps "Libre Software" is a better starting description here
  - rascul 4y ago
    The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.
    - nicoburns 4y ago
      > free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is another sense entirely. Is this a cultural reference I'm missing?
      - dolni 4y ago
        The first amendment to the US Constitution provides very strong protection for the right to free speech. Presumably that is the origin of "free as in speech".
        nicoburns 4y ago
        Right, but what about "free as in beer"?
sdfhdhjdw3 4y ago
What does a "front-end" mean exactly, in this context?
- stevewatson301 4y ago
  The part of a compiler that handles tokenization, parsing, AST generation and IR emission, as opposed to the backend which is responsible for conversion of IR to a target-compatible executable.
- colejohnson66 4y ago
  At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if you wanted to expand to, say, ARM, Alpha, etc. targets, it gets worse. You end up needing O(l*t) compilers[a] to be homogenous. It gets even worse if you want to add optimization. With this model, the whole system is working on an AST, and therefore, the optimizers are tailored to the individual compiler varient, so they end up being just as unportable. However, with a modular design (front and back end), you can have C->IR and Fortran->IR front ends, then a single back end for each target: IR->x86 and IR->ARM. If you want to add, say, Ada support, you only need to write an Ada->IR module, and the back ends handle the rest. In the end, you only need O(l+t) modules. You also get the benefit of agnostic optimizers as they only need to support your internal IR. [a]: 'l' is languages and 't' is targets
  - bombcar 4y ago
    Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?
    - Blackthorn 4y ago
      At some point in history there was a jvm chip like that. It's long gone, not sure for what reason.
pabs3 4y ago
Another related project is the libgccjit backend for rustc: https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc
- deleted 4y ago
  [deleted]
- stjohnswarts 4y ago
  Lots of people are spending time with libgccjit for compiling Emacs modules to speed them up with the "native compiled" version of emacs. I've tried it with doom emacs and it definitely speeds up things and seems stable enough.
Galanwe 4y ago
Does this mean we could have Rust for AVR? Without all the quirks and schrodinbugs of LLVM AVR on Harvard architectures.
- bombela 4y ago
  In the past month or so, the latest version of rustc/llvm seems to produce correct machine code. It was very rough for a couple in years though.
  - dcormier 4y ago
    Oh, I hadn’t seen that. That’s exciting.
deleted 4y ago
[deleted]
rob74 4y ago
I'm not sure if this is such a good idea at this point in the evolution of Rust? I mean, Go has a comparatively "tame" pace of changes, but gccgo is still always several months behind gc (which refers to the most-used go compiler, not garbage collection). With the higher volume of changes in Rust, lots of features will be unavailable in gccrust for what will probably feel like ages to some...
- sillysaurusx 4y ago
  I think the difference is that Go is less active than Rust. It might turn out to be a bad idea. But at this point, gcc needs to try something to stay relevant. This is the first piece of news about gcc that made me go "whoa" in the last couple years.
- OskarS 4y ago
  I think having some diversity in the Rust compiler space is an excellent idea. The rustc monoculture is really bad in the long-term, having multiple compilers allows for creating a much more robust standard (so that implementation bugs doesn't get "baked in" to the language) and benchmarking compile times as well as resulting binaries (in addition to many other benefits). You're right that GCC Rust will probably be behind rustc for a while, but the sooner you start, the sooner it'll get there. The language isn't gonna "settle down" in that way any time soon, might as well just get going as soon as possible.
  - cogman10 4y ago
    > The language isn't gonna "settle down" in that way any time soon Actually, I'd say the language HAS settled down. Most new releases are stabilizing APIs or general tooling improvements and not actual language changes. Not to say there aren't outstanding tweaks, adjustments, or improvements to the language that are ongoing, but rather, the target isn't moving nearly as fast as it was when 1.0 or rust 2018 were released.
- wging 4y ago
  FWIW, it does appear that at least for now, the project is targeting a version of Rust that is substantially behind the current stable version: > For some context, my current project plan brings us to November 2022 > where we (unexpected events permitting) should be able to support > valid Rust code targeting Rustc version ~1.40 and reuse libcore, (current stable rustc is 1.62, 1.40 is from Dec. 19, 2019) Which is in line with what you're saying about gcc likely being behind initially, of course. I bet it's easier to go from version 1.40 to 1.6x than from version nil to 1.40, though - you have to start somewhere, and the later you start, the longer till you have a viable alternative.
SnowHill9902 4y ago
The vote of confidence I was waiting for.
thealienthing 4y ago
Does having rust support for GCC mean potentially faster rust compiler times compared to comping off of LLVM platform?
- stjohnswarts 4y ago
  I mean maybe, sure? I don't think that's their end goal, as their main purpose is to have a gcc version for gcc folks, whether it's faster or slower than llvm isn't a goal though. I think first goal is to get it done and stable and forces in place to keep up with the ever updating Rust spec(s). It would also allow for a much wider number of platforms as gcc compiler is much higher coverage of platforms especially legacy ones.
- Ericson2314 4y ago
  Doubt it. But that's OK.
- ArrayBoundCheck 4y ago
  No. LLVM is faster than GCC so most likely it'll be slower. If the way the frontend generates code for the backend is completely different then there's a chance it won't be terrible and will have reasonable build speeds. However there's a chance it'll be inconsistent with llvm output but chances are noone will notice or care if it's not buggy
- nickitolas 4y ago
  I doubt it, specially if you compare agains the GCC rustc backend. I would expect most of the difference (If any) to come from the frontend. For example, if it doesn't do borrow checking, it might be able to shave off a bit of time. But at that point, it highly depends on the workload (i.e the code you're compiling). I would expect the vast majority of rust code to bottleneck on codegen, in which case there should be approximately 0 difference. For code bottlenecked on borrow checking (Which I would expect to be an outlier), gccrs should be faster while ignoring borrow checking (Although my understanding is they plan to eventually use polonius for borrow checking, a rust library/project that originally intended to replace the current borrow checker in rustc but still hasn't. In which case, it would probably be faster for some borrow checking and slower for others)
faisal_ksa 4y ago
What is the benefit of having multiple compilers for programming languages? Is there a scenario where a GCC compiled rust program would do something that an LLVM one can't do? Doesn't this cause fragmentation in the rust ecosystem? P.S.:I understand that people can work on any project they want. And I don't have the right to tell them not to. I'm just curious about the technical reasons for having multiple compilers.
- davidatbu 4y ago
  This is answered in various replies to other comments.
- zetaposter 4y ago
  1. GCC has more backends than LLVM. 2. Competition is good in general. 3. I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.
  - faisal_ksa 4y ago
    Thank you so much. The specification point is very important
  - israrkhan 4y ago
    and to back up your point... There should be at least 2 implementations for anything to be a spec/standard.
  - tomjakubowski 4y ago
    Being on gcc, a long-lived platform, also helps ensure the survival of the language even if development of the current compiler (or LLVM) dies or withers.
    - duckerude 4y ago
      Does it? GCC's Java frontend died and is no longer shipped, they need maintainers like any other compiler.
gccsucksornot 4y ago
- mixedCase 4y ago
  What are you quoting? And making an account just for a comment goes against HN guidelines: > Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.
superkuh 4y ago
Hopefully this will slow down development of new Rust features to a reasonable pace. Instead of Rust devs writing code that requires a new compiler every 3 months it'll be more like every year or two. Almost useable.
- dagmx 4y ago
  This is an odd take that I feel is rooted in a misunderstanding. rust intentionally has a fairly rapid release schedule, so that you don't end up with a big release every year that introduces several possibly breaking changes. Features aren't randomly scheduled for each release. Instead each release is a snapshot of what's been stabilized by that point. If you prefer some arbitrary concept of stability, then you can quite easily lock to any version of rust this far and ignore any new versions till something catches your fancy.
  - superkuh 4y ago
    This is the perspective of a developer. I am trying to explain the perspective of an open source desktop user who's ran into the backwards incompatibility in 4 out of 5 rust tools I've attempted to compile for use. The Rust language is fine. Great, even. Most Rust devs are bleeding edge types that always use the latest features. Hopefully this changes as Rust matures.
    - dagmx 4y ago
      The rust compiler rarely breaks backwards compatibility, so I'd be curious to see what issues you actually hit. Perhaps you mean forwards compatibility, in which case yes perhaps that's an issue but I'm not sure why you'd want bigger, slower release cadence when it would likely make your problem worse , when libs update but updating your compiler potentially causes significant other changes as is the case with C++ for example
    - tialaramex 4y ago
      I feel like the set of people who * Want to compile the software, not just install a pre-built binary * But, don't want to actually hack on the software and so don't care about up-to-date tools ... is probably rather small. Even for them, though, surely just an old source version will work? Or is there some reason that doesn't help?
j16sdiz 4y ago
The rust borrow checker is under-specified (for a good reason). Can forsee lots of incompatible with two implementation
- yjftsjthsd-h 4y ago
  What good reason would there be for under-specifying it, that would create problems? Like, I can see wanting to leave flexibility in the implementation, but then different implementations should be fine if they both match what spec there is. The only problem would be if one implementation is more strict than it "admits" to being (in its written spec), which is a problem anyways.
  - kelnos 4y ago
    I think there are two things that could be specified here: 1. What the borrow checker protects against, and what constitutes valid code. 2. What the borrow checker can actually prove is valid code. #2 tends to be much less than #1, because the compiler can only be so smart, and if it can't prove something correct (even if it might be correct), it takes the safe route and refuses to compile the code. #1 is probably pretty well specified, or at least wouldn't be hard to write down if someone really wanted to. #2 is a moving target, because the borrow checker in rustc gets smarter with some releases, and compiles code that it used to reject (because it's been taught to understand that code better and can prove it correct). So it's a lot harder to specify exactly what kinds of code the borrow checker will accept and reject. I could easily see a situation where gcc-rust claims to support all the language and stdlib features that a particular version of rustc supports, but has subtle differences in borrow checker behavior that causes it to reject some code that rustc accepts (or accept some code that rustc rejects). The behavior isn't incorrect, per se, but it would be frustrating for developers. It's also possible there could be similar issues with lifetime analysis.
- kelnos 4y ago
  Yeah, this would worry me too. It feels like the rustc policy on this is just to make the compiler smarter and smarter so it can accept more code that's actually valid (but couldn't prove was the case in previous versions). That's a great goal, but that makes it really hard to nail down what is and isn't allowed in a particular version of Rust. And if we assume that gcc Rust will always be playing catch-up to rustc, they will probably have a hard time enumerating rustc's borrow checker's behavior precisely enough to be able to replicate its behavior exactly in gcc Rust. So that means some code that rustc is ok with, gcc Rust might not be, and vice versa (even though all the code might be fine).
cosmiccatnap 4y ago
Typical desktop Linux is compiled with gcc and even if rust features in gcc lag behind rustc this is still a great step in the direction of one of the larger goals many of us want from rust which is to replace C as a memory safe systems language for OS kernel and embedded projects. A big part of getting a sane environment to build rust Linux modules is having it easily integrate with the gcc toolchain. There seems to be some contention around if this is a good idea for rust as a language itself and my counter to that would be that there are billions of people on the planet and the work integrating rust into gcc doesn't detract in any way I can see from the continued development of rust as a language, it just helps to make it more viable for many use cases and therefore increase it's footprint and overall support.
mbStavola 4y ago
I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers of entry, the better. But on the other hand, I don't want to have to think of implementation specific behaviors, bugs, quirks, et cetera. Having an ecosystem built with thousands of people wrestling with that problem seems like a recipe for buggy software and burnout. People say that a spec would help with this aspect but I'm sceptical; a spec doesn't prevent divergence from happening, it just gives you a frame of reference for what is correct. You also don't need multiple implementations to have a spec either! I fear that the way this is going to pan out is that we'll have multiple frontends for Rust, but the vast majority of engineers using the language will only ever think about "true" Rust: the current mainstream implementation. Issues in crates that primarily affect "alternative" Rusts will go unacknowledged, be tossed out, or have hacky patch jobs. We'll end up with either a) two separate, but high quality, ecosystems or b) one shared, lower quality ecosystem that is constantly fighting itself. I hold Rust in really high regard and it's my favorite language at the moment, so this thought is scary to me. Though, there are a lot of smart people involved so maybe it doesn't have to be so doom and gloom. A couple of years ago I thought that cross-platform software was really messy and hard to get right but languages like Rust have the proper language features to make things like this much easier (though not perfect!). It could be that the emergence of multiple frontends could necessitate features and tooling for the Rust itself which makes all of that I said a non-issue. Maybe. Hopefully.
- deleted 4y ago
  [deleted]
- mcdonje 4y ago
  Pretty sure you have it backwards. GCC isn't going to be a front end for rust; rust is going to be a front end for GCC. As I understand it, the point of both GCC and LLVM are to handle those implementation specific behaviors so programming language developers don't have to handle that concern. I don't expect this to fracture the language, but simply to provide the ability to use the language in more places.
akoster 4y ago
Great news! Hopefully this means that Rust will now support GCC's supported architectures [0] in addition to their own quite impressive and continuously improving list [1] [2], including those that are less popular these days. I hope this will directly help issues experienced by the Debian Ports project [3] [4], Gentoo Linux [5] [6], and possibly Alpine Linux [7] and NetBSD [8]. [0] https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html [1] https://doc.rust-lang.org/rustc/target-tier-policy.html https://doc.rust-lang.org/rustc/target-tier-policy.html [2] https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm... [3] https://web.archive.org/web/20220223133124/https://people.gnome.org/~federico/blog/librsvg-rust-and-non-mainstream-architectures.html https://web.archive.org/web/20220223133124/https://people.gn... [4] https://lwn.net/Articles/771355/ https://lwn.net/Articles/771355/ [5] https://news.ycombinator.com/item?id=26097153 https://news.ycombinator.com/item?id=26097153 [6] https://news.ycombinator.com/item?id=26203853 https://news.ycombinator.com/item?id=26203853 [7] https://wiki.alpinelinux.org/wiki/Architecture https://wiki.alpinelinux.org/wiki/Architecture [8] https://www.netbsd.org/ports/#ports-by-cpu https://www.netbsd.org/ports/#ports-by-cpu
- nickitolas 4y ago
  That is actually going to happen for rustc itself via the rustc_codegen_gcc project (https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc), this post is about a different project that writes a "from scratch" rust frontend/compiler for the GCC project in C++ . They both compile rust code with GCC as a backend, but one uses the normal rustc/cargo tools, and the other is a separate compiler with a separate cargo shim.
lumost 4y ago
This is very exciting for a large C/C++ project I work on. From what I understand, someone could reasonably pilot a single Rust module to see how things go without shaking up the entire build system.
OptionX 4y ago
Rust newbie that has used part of his summer to get into Rust. Clarify me on some points. Does that means than (after merged) I can use gcc to compile rust code right? What are the advantages of this versus using the normal rustc compiler? All the crate/project management would still be done with cargo? It seems to be a tool very entwined with rust itself, so I wonder if someone uses rust without cargo?
- pabs3 4y ago
  I think most people would just use the existing Rust infrastructure; rustc etc. The GCC frontend will be useful in situations where you cannot use that; for platforms that LLVM/rustc do not support, when you want to build rustc from source instead of using the rustc binaries etc.
Aissen 4y ago
Just like Mozilla's browser might be eventually a footnote in history (I hope not), this too has a potential impact greater than Open Source Security's main project (grsecurity). Kudos.
- pjmlp 4y ago
  At 3% market share it looks it might be eventually become true, and it is my favourite browser still.

436 points by edelsohn 4y ago

maxyurk 4y ago

a naive question - would it be faster than the "regular" rust compiler?

cogman10 4y ago
I can't seem to find any benchmarks around it. I'm assuming as this gets further integrated into GCC, you'll start to see those crop up.

fbanon 4y ago

klez 4y ago
Care to elaborate?
- kangalioo 4y ago
  Maybe referring to the fact that GCCRS duplicates a ton of effort by reimplementing the frontend (parser, borrow checker, error messages etc.) for questionable benefit since you could keep the existing frontend and just swap out the LLVM backend for GCC (as done by the rustc_codegen_gcc project).
  - wtetzner 4y ago
    This ignores the benefits of having multiple implementations, e.g. you can use places where two implementations disagree with each other to track down bugs in one or both of them.

outside1234 4y ago

Why would someone want this? (Honest question)

dleslie 4y ago
Gcc has more stable hardware targets than llvm, for starters.
- pavon 4y ago
  Note that there is a separate project to use the GCC backend with the Rustc frontend. At least in the short-term, that project will be the better approach to providing the benefits of more hardware support, since it will be more complete and compatible with the rustc/llvm compiler. The main benefit of a GCC front-end is to move Rust beyond a single vendor, and shakeout ambiguities in the (informal) language specification.
mistrial9 4y ago
alternate architectures; plurality
- nickitolas 4y ago
  Isn't this already addressed by the GCC backend for rustc? (Via libgccjit)
twic 4y ago
Multiple implementations of a standard help shine light into dark corners.
- pca006132 4y ago
  Indeed, but I think they should first create a standard?
  - rob74 4y ago
    If not a standard, then at least a specification. This discussion is from 2020, so I'm not sure if it's still up to date: https://users.rust-lang.org/t/where-is-the-rust-language-specification/42047 https://users.rust-lang.org/t/where-is-the-rust-language-spe... "For the most part though, rustc itself is the spec" - so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? And try to keep up with all the changes which will inevitably happen in the LLVM frontend while you are implementing the GCC frontend?

dleslie 4y ago

This is great! Gcc support opens up more platforms, more targets, and the opportunity to more easily integrate with the various common embedded toolchains that are built around gcc. And it's free software, for those that care, this matters.

mistrial9 4y ago
> free software it seems like this term is misunderstood in English to mean "no money" .. perhaps "Libre Software" is a better starting description here
- rascul 4y ago
  The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.
  - nicoburns 4y ago
    > free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is another sense entirely. Is this a cultural reference I'm missing?
    - dolni 4y ago
      The first amendment to the US Constitution provides very strong protection for the right to free speech. Presumably that is the origin of "free as in speech".
      - nicoburns 4y ago
        Right, but what about "free as in beer"?

sdfhdhjdw3 4y ago

What does a "front-end" mean exactly, in this context?

stevewatson301 4y ago
The part of a compiler that handles tokenization, parsing, AST generation and IR emission, as opposed to the backend which is responsible for conversion of IR to a target-compatible executable.
colejohnson66 4y ago
At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if you wanted to expand to, say, ARM, Alpha, etc. targets, it gets worse. You end up needing O(l*t) compilers[a] to be homogenous. It gets even worse if you want to add optimization. With this model, the whole system is working on an AST, and therefore, the optimizers are tailored to the individual compiler varient, so they end up being just as unportable. However, with a modular design (front and back end), you can have C->IR and Fortran->IR front ends, then a single back end for each target: IR->x86 and IR->ARM. If you want to add, say, Ada support, you only need to write an Ada->IR module, and the back ends handle the rest. In the end, you only need O(l+t) modules. You also get the benefit of agnostic optimizers as they only need to support your internal IR. [a]: 'l' is languages and 't' is targets
- bombcar 4y ago
  Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?
  - Blackthorn 4y ago
    At some point in history there was a jvm chip like that. It's long gone, not sure for what reason.

pabs3 4y ago

Another related project is the libgccjit backend for rustc: https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc

deleted 4y ago
[deleted]
stjohnswarts 4y ago
Lots of people are spending time with libgccjit for compiling Emacs modules to speed them up with the "native compiled" version of emacs. I've tried it with doom emacs and it definitely speeds up things and seems stable enough.

Galanwe 4y ago

Does this mean we could have Rust for AVR? Without all the quirks and schrodinbugs of LLVM AVR on Harvard architectures.

bombela 4y ago
In the past month or so, the latest version of rustc/llvm seems to produce correct machine code. It was very rough for a couple in years though.
- dcormier 4y ago
  Oh, I hadn’t seen that. That’s exciting.

deleted 4y ago

[deleted]

rob74 4y ago

I'm not sure if this is such a good idea at this point in the evolution of Rust? I mean, Go has a comparatively "tame" pace of changes, but gccgo is still always several months behind gc (which refers to the most-used go compiler, not garbage collection). With the higher volume of changes in Rust, lots of features will be unavailable in gccrust for what will probably feel like ages to some...

sillysaurusx 4y ago
I think the difference is that Go is less active than Rust. It might turn out to be a bad idea. But at this point, gcc needs to try something to stay relevant. This is the first piece of news about gcc that made me go "whoa" in the last couple years.
OskarS 4y ago
I think having some diversity in the Rust compiler space is an excellent idea. The rustc monoculture is really bad in the long-term, having multiple compilers allows for creating a much more robust standard (so that implementation bugs doesn't get "baked in" to the language) and benchmarking compile times as well as resulting binaries (in addition to many other benefits). You're right that GCC Rust will probably be behind rustc for a while, but the sooner you start, the sooner it'll get there. The language isn't gonna "settle down" in that way any time soon, might as well just get going as soon as possible.
- cogman10 4y ago
  > The language isn't gonna "settle down" in that way any time soon Actually, I'd say the language HAS settled down. Most new releases are stabilizing APIs or general tooling improvements and not actual language changes. Not to say there aren't outstanding tweaks, adjustments, or improvements to the language that are ongoing, but rather, the target isn't moving nearly as fast as it was when 1.0 or rust 2018 were released.
wging 4y ago
FWIW, it does appear that at least for now, the project is targeting a version of Rust that is substantially behind the current stable version: > For some context, my current project plan brings us to November 2022 > where we (unexpected events permitting) should be able to support > valid Rust code targeting Rustc version ~1.40 and reuse libcore, (current stable rustc is 1.62, 1.40 is from Dec. 19, 2019) Which is in line with what you're saying about gcc likely being behind initially, of course. I bet it's easier to go from version 1.40 to 1.6x than from version nil to 1.40, though - you have to start somewhere, and the later you start, the longer till you have a viable alternative.

SnowHill9902 4y ago

The vote of confidence I was waiting for.

thealienthing 4y ago

Does having rust support for GCC mean potentially faster rust compiler times compared to comping off of LLVM platform?

stjohnswarts 4y ago
I mean maybe, sure? I don't think that's their end goal, as their main purpose is to have a gcc version for gcc folks, whether it's faster or slower than llvm isn't a goal though. I think first goal is to get it done and stable and forces in place to keep up with the ever updating Rust spec(s). It would also allow for a much wider number of platforms as gcc compiler is much higher coverage of platforms especially legacy ones.
Ericson2314 4y ago
Doubt it. But that's OK.
ArrayBoundCheck 4y ago
No. LLVM is faster than GCC so most likely it'll be slower. If the way the frontend generates code for the backend is completely different then there's a chance it won't be terrible and will have reasonable build speeds. However there's a chance it'll be inconsistent with llvm output but chances are noone will notice or care if it's not buggy
nickitolas 4y ago
I doubt it, specially if you compare agains the GCC rustc backend. I would expect most of the difference (If any) to come from the frontend. For example, if it doesn't do borrow checking, it might be able to shave off a bit of time. But at that point, it highly depends on the workload (i.e the code you're compiling). I would expect the vast majority of rust code to bottleneck on codegen, in which case there should be approximately 0 difference. For code bottlenecked on borrow checking (Which I would expect to be an outlier), gccrs should be faster while ignoring borrow checking (Although my understanding is they plan to eventually use polonius for borrow checking, a rust library/project that originally intended to replace the current borrow checker in rustc but still hasn't. In which case, it would probably be faster for some borrow checking and slower for others)

faisal_ksa 4y ago

What is the benefit of having multiple compilers for programming languages? Is there a scenario where a GCC compiled rust program would do something that an LLVM one can't do? Doesn't this cause fragmentation in the rust ecosystem? P.S.:I understand that people can work on any project they want. And I don't have the right to tell them not to. I'm just curious about the technical reasons for having multiple compilers.

davidatbu 4y ago
This is answered in various replies to other comments.
zetaposter 4y ago
1. GCC has more backends than LLVM. 2. Competition is good in general. 3. I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.
- faisal_ksa 4y ago
  Thank you so much. The specification point is very important
- israrkhan 4y ago
  and to back up your point... There should be at least 2 implementations for anything to be a spec/standard.
- tomjakubowski 4y ago
  Being on gcc, a long-lived platform, also helps ensure the survival of the language even if development of the current compiler (or LLVM) dies or withers.
  - duckerude 4y ago
    Does it? GCC's Java frontend died and is no longer shipped, they need maintainers like any other compiler.

gccsucksornot 4y ago

mixedCase 4y ago
What are you quoting? And making an account just for a comment goes against HN guidelines: > Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.

superkuh 4y ago

Hopefully this will slow down development of new Rust features to a reasonable pace. Instead of Rust devs writing code that requires a new compiler every 3 months it'll be more like every year or two. Almost useable.

dagmx 4y ago
This is an odd take that I feel is rooted in a misunderstanding. rust intentionally has a fairly rapid release schedule, so that you don't end up with a big release every year that introduces several possibly breaking changes. Features aren't randomly scheduled for each release. Instead each release is a snapshot of what's been stabilized by that point. If you prefer some arbitrary concept of stability, then you can quite easily lock to any version of rust this far and ignore any new versions till something catches your fancy.
- superkuh 4y ago
  This is the perspective of a developer. I am trying to explain the perspective of an open source desktop user who's ran into the backwards incompatibility in 4 out of 5 rust tools I've attempted to compile for use. The Rust language is fine. Great, even. Most Rust devs are bleeding edge types that always use the latest features. Hopefully this changes as Rust matures.
  - dagmx 4y ago
    The rust compiler rarely breaks backwards compatibility, so I'd be curious to see what issues you actually hit. Perhaps you mean forwards compatibility, in which case yes perhaps that's an issue but I'm not sure why you'd want bigger, slower release cadence when it would likely make your problem worse , when libs update but updating your compiler potentially causes significant other changes as is the case with C++ for example
  - tialaramex 4y ago
    I feel like the set of people who * Want to compile the software, not just install a pre-built binary * But, don't want to actually hack on the software and so don't care about up-to-date tools ... is probably rather small. Even for them, though, surely just an old source version will work? Or is there some reason that doesn't help?

j16sdiz 4y ago

The rust borrow checker is under-specified (for a good reason). Can forsee lots of incompatible with two implementation

yjftsjthsd-h 4y ago
What good reason would there be for under-specifying it, that would create problems? Like, I can see wanting to leave flexibility in the implementation, but then different implementations should be fine if they both match what spec there is. The only problem would be if one implementation is more strict than it "admits" to being (in its written spec), which is a problem anyways.
- kelnos 4y ago
  I think there are two things that could be specified here: 1. What the borrow checker protects against, and what constitutes valid code. 2. What the borrow checker can actually prove is valid code. #2 tends to be much less than #1, because the compiler can only be so smart, and if it can't prove something correct (even if it might be correct), it takes the safe route and refuses to compile the code. #1 is probably pretty well specified, or at least wouldn't be hard to write down if someone really wanted to. #2 is a moving target, because the borrow checker in rustc gets smarter with some releases, and compiles code that it used to reject (because it's been taught to understand that code better and can prove it correct). So it's a lot harder to specify exactly what kinds of code the borrow checker will accept and reject. I could easily see a situation where gcc-rust claims to support all the language and stdlib features that a particular version of rustc supports, but has subtle differences in borrow checker behavior that causes it to reject some code that rustc accepts (or accept some code that rustc rejects). The behavior isn't incorrect, per se, but it would be frustrating for developers. It's also possible there could be similar issues with lifetime analysis.
kelnos 4y ago
Yeah, this would worry me too. It feels like the rustc policy on this is just to make the compiler smarter and smarter so it can accept more code that's actually valid (but couldn't prove was the case in previous versions). That's a great goal, but that makes it really hard to nail down what is and isn't allowed in a particular version of Rust. And if we assume that gcc Rust will always be playing catch-up to rustc, they will probably have a hard time enumerating rustc's borrow checker's behavior precisely enough to be able to replicate its behavior exactly in gcc Rust. So that means some code that rustc is ok with, gcc Rust might not be, and vice versa (even though all the code might be fine).

cosmiccatnap 4y ago

Typical desktop Linux is compiled with gcc and even if rust features in gcc lag behind rustc this is still a great step in the direction of one of the larger goals many of us want from rust which is to replace C as a memory safe systems language for OS kernel and embedded projects. A big part of getting a sane environment to build rust Linux modules is having it easily integrate with the gcc toolchain. There seems to be some contention around if this is a good idea for rust as a language itself and my counter to that would be that there are billions of people on the planet and the work integrating rust into gcc doesn't detract in any way I can see from the continued development of rust as a language, it just helps to make it more viable for many use cases and therefore increase it's footprint and overall support.

mbStavola 4y ago

I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers of entry, the better. But on the other hand, I don't want to have to think of implementation specific behaviors, bugs, quirks, et cetera. Having an ecosystem built with thousands of people wrestling with that problem seems like a recipe for buggy software and burnout. People say that a spec would help with this aspect but I'm sceptical; a spec doesn't prevent divergence from happening, it just gives you a frame of reference for what is correct. You also don't need multiple implementations to have a spec either! I fear that the way this is going to pan out is that we'll have multiple frontends for Rust, but the vast majority of engineers using the language will only ever think about "true" Rust: the current mainstream implementation. Issues in crates that primarily affect "alternative" Rusts will go unacknowledged, be tossed out, or have hacky patch jobs. We'll end up with either a) two separate, but high quality, ecosystems or b) one shared, lower quality ecosystem that is constantly fighting itself. I hold Rust in really high regard and it's my favorite language at the moment, so this thought is scary to me. Though, there are a lot of smart people involved so maybe it doesn't have to be so doom and gloom. A couple of years ago I thought that cross-platform software was really messy and hard to get right but languages like Rust have the proper language features to make things like this much easier (though not perfect!). It could be that the emergence of multiple frontends could necessitate features and tooling for the Rust itself which makes all of that I said a non-issue. Maybe. Hopefully.

deleted 4y ago
[deleted]
mcdonje 4y ago
Pretty sure you have it backwards. GCC isn't going to be a front end for rust; rust is going to be a front end for GCC. As I understand it, the point of both GCC and LLVM are to handle those implementation specific behaviors so programming language developers don't have to handle that concern. I don't expect this to fracture the language, but simply to provide the ability to use the language in more places.

akoster 4y ago

Great news! Hopefully this means that Rust will now support GCC's supported architectures [0] in addition to their own quite impressive and continuously improving list [1] [2], including those that are less popular these days. I hope this will directly help issues experienced by the Debian Ports project [3] [4], Gentoo Linux [5] [6], and possibly Alpine Linux [7] and NetBSD [8]. [0] https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html [1] https://doc.rust-lang.org/rustc/target-tier-policy.html https://doc.rust-lang.org/rustc/target-tier-policy.html [2] https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm... [3] https://web.archive.org/web/20220223133124/https://people.gnome.org/~federico/blog/librsvg-rust-and-non-mainstream-architectures.html https://web.archive.org/web/20220223133124/https://people.gn... [4] https://lwn.net/Articles/771355/ https://lwn.net/Articles/771355/ [5] https://news.ycombinator.com/item?id=26097153 https://news.ycombinator.com/item?id=26097153 [6] https://news.ycombinator.com/item?id=26203853 https://news.ycombinator.com/item?id=26203853 [7] https://wiki.alpinelinux.org/wiki/Architecture https://wiki.alpinelinux.org/wiki/Architecture [8] https://www.netbsd.org/ports/#ports-by-cpu https://www.netbsd.org/ports/#ports-by-cpu

nickitolas 4y ago
That is actually going to happen for rustc itself via the rustc_codegen_gcc project (https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc), this post is about a different project that writes a "from scratch" rust frontend/compiler for the GCC project in C++ . They both compile rust code with GCC as a backend, but one uses the normal rustc/cargo tools, and the other is a separate compiler with a separate cargo shim.

lumost 4y ago

This is very exciting for a large C/C++ project I work on. From what I understand, someone could reasonably pilot a single Rust module to see how things go without shaking up the entire build system.

OptionX 4y ago

Rust newbie that has used part of his summer to get into Rust. Clarify me on some points. Does that means than (after merged) I can use gcc to compile rust code right? What are the advantages of this versus using the normal rustc compiler? All the crate/project management would still be done with cargo? It seems to be a tool very entwined with rust itself, so I wonder if someone uses rust without cargo?

pabs3 4y ago
I think most people would just use the existing Rust infrastructure; rustc etc. The GCC frontend will be useful in situations where you cannot use that; for platforms that LLVM/rustc do not support, when you want to build rustc from source instead of using the rustc binaries etc.

Aissen 4y ago

Just like Mozilla's browser might be eventually a footnote in history (I hope not), this too has a potential impact greater than Open Source Security's main project (grsecurity). Kudos.

pjmlp 4y ago
At 3% market share it looks it might be eventually become true, and it is my favourite browser still.