As long as the Rust language specification isn't stable, GCC's Rust implementation would just fall behind all the time.
As an alternative, it has been suggested providing a GCC frontend for the LLVM-IR language which is generated by the Rust compiler since that specification is stable.
If Rust's specification becomes stable at some point, it would probably a good idea to start a Bountysource campaign (like we recently did for the m68k  and AVR backends ) to help the Rust frontend brushed up and ready for being merged into the GCC source tree.
>  https://www.bountysource.com/issues/80706251-m68k-convert-th...
>  https://www.bountysource.com/issues/84630749-avr-convert-the...
Compare that to C/C++ which has new releases every 3 years. A compiler that only supports C++14 is still perfectly usable for most C++ codebases out there. In fact, Godot engine still hasn't migrated to C++11 yet, and it's no exception from the norm at all. Even if your compiler has parity with Rust 1.31, released one year ago, you'll have trouble with most projects as even if the project itself doesn't depend on newer compiler releases, one of the transitive dependencies will.
I also just realized that it's not the same backend as the one written by "redbrain" here .
>  https://github.com/redbrain/gccrs
gcc-rust currently needs LLVM to build because that's the only good way to build Rust code, and gcc-rust (unlike, say, mrustc) uses Rust code. Once gcc-rust is on track, Rust code used by gcc-rust can be built by gcc-rust, and LLVM becomes unnecessary.
Interesting. This is the first I've heard of Cranelift being used as anything other than a code generator for wasm runtimes. When would Cranelift be used instead of LLVM, and vice versa?
But I would expect in a few more years we'll see the rate of Rust language change will be significantly lower.
The (simplified) way that rustc works is that it translates Rust source code into a custom intermediate language called MIR, does a bunch of analysis and a few optimizations, and at the very end translates MIR to LLVM IR and passes that into LLVM. This project looks to add support for translating MIR to GCC's own IR instead of LLVM IR, allowing it to reuse all the other work that has been done writing rustc.
For a from-scratch reimplementation of (most of) a Rust frontend, see mrustc ( https://github.com/thepowersgang/mrustc ), which is written in C++, and served to demonstrate that (a prior version of) rustc did not feature a reflections-on-trusting-trust attack (via diverse double compilation).
FWIW, there is an out-of-tree m68k backend for LLVM . I have already done some experimental work on Rust for m68k based on this backend .
>  https://github.com/M680x0/M680x0-llvm/
>  https://github.com/glaubitz/rust/tree/m68k-linux
* Alpha is more than a decade past end of life.
* Hppa is EOL as of 6 years ago.
* ia64 goes EOL next month.
.. and the list goes on. These aren't going concerns outside of some hobbyist work, and GCC has had difficulty retaining maintainers for some of the hardware and has threatened deprecation of them (in fact IA-64 is facing this exact situation and is going to be marked deprecated in GCC 10, and vanish in 11 https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html). With instruction set support in that state, the odds are reasonable that bugs will be exposed, and difficulty will be had trying to support and fix them (exasperated by scarcity of hardware)
Adding support for obsolete hardware is not much of a good argument for taking on the work of supporting two compilers.
I would welcome another rust compiler as it would give us choices.
Why was MIR chosen instead of WASM?
MIR is Rust's accurate low-level representation with much more type information, and it's aware of native target's specification, so it can be optimized better, and has better interoperability with native code.
But rust in the general case is agnostic about 32 vs 64 bit pointers and explicitly targets WASM.
I'm not familiar with GCC's IR, but unsandboxed AOT WASM compiled thru LLVM IR is astoundingly fast.
> This average benchmark has speed in microseconds and is compiled using GCC -O3 –march=native on WSL. “We usually see 75% native speed with sandboxing and 95% without. The C++ benchmark is actually run twice – we use the second run, after the cache has had time to warm up. Turning on fastmath for both inNative and GCC makes both go faster, but the relative speed stays the same”, the official website reads.
> “The only reason we haven’t already gotten to 99% native speed is because WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing”, the WebAssembly researcher mentions. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, as this vectorization analysis will have happened before the WebAssembly compilation step.
It's important for core infrastructure to have multiple competing implementations. On a related note, does Rust have a standard yet or are they still doing the reference implementation thing?
> I was under the impression that llvm is better than gcc?
And I thought that tabs were better than spaces, BSD beat Linux, Emacs was the one true god... what were we arguing about again?
I'd be curious to know whether this would provide cross-language outlining during LTO using gcc. I believe some form of this is possible with llvm?
For many practical purposes I think the closest thing to a language definition is the set of testsuites visible to Crater.
(That is: when the compiler people are considering a change, they don't say "we can't change this because we're past 1.0 and the change is technically backwards-incompatible", or "we can't change this because the Reference specifies the current behaviour"; they say "let's do a Crater run and see if anything breaks".)
It’s a bit weird how laser-focused the Rust community is on backwards compatibility, not seeming to believe that forward compatibility is also important.
e.g., if I write code targeting C++17, I can be reasonably sure it compiles with an older version of the compiler, as long as that version also claims to support C++17, modulo bugs. Not the case if I write code targeting Rust 2015 as they’re still adding features to that from time to time. Let alone Rust 2018 which changes every 6 weeks.
Will there ever be a version of Rust that the community agrees “OK, this language definition is not changing unless we find some major soundness bug” ?
This is a big blocker for mainstream adoption in Linux distributions since the maintainer wants to be able to land one specific version of rustc in the repositories, not rely on people downloading new versions with rustup continuously. But old versions of rustc are effectively useless due to the lack of forward compatibility guarantees.
g++ 4.4 implemented several key parts of C++11, including notably rvalue references, and adapted libstdc++ to use rvalue references in C++11 mode. However, the committee had to make major revisions to rvalue references subsequent to this implementation, to the point that you can't use libstdc++ 4.4's header files (such as <vector>) with a compliant C++11 compiler. So when you try to use newer clang (which prefers to use system libstdc++ for ABI reasons) on systems with 4.4 installed (because conservative IT departments), the result is lots and lots of pain.
Furthermore, it absolutely is the case that newer versions of compilers will interpret old language standards differently than older versions of the compiler. You don't notice it for the most part because the changes tend to revolve around pretty obscure language wordings involving combinations of features that most people won't hit. Compilers are going to try hard not to care about language versions past the frontend of the compiler--if the specification change lies entirely in the middle or backend, then that change is likely to be retroactively applied to past versions because otherwise the plumbing necessary is too difficult.
Rust dearly needs a stable specification, it is the main blocker why the language hasn't been more widely adopted.
E.g., if someone thinks "I'm going to target 2015 because I want my code to run on the rustc shipped with various slow-moving Linux distros", it doesn't help, because you might still not be able to target their code, unless they specifically target an older version of rustc, which nobody does.
It really depends on how strictly you define the term specification. The Rust Reference is not required to be accurate. Though many other language compilers/implementations don’t fully implement their respective specs so, :shrug:.
If I have a question whose answer isn't obvious, it's far more likely that I have to go trawling around in RFCs than that there's an answer in the reference.
I think most languages of a similar age (eg Go, Swift) are doing better.
Could you site sources please?
Now, in terms of end results, llvm and gcc each have their qualities. When llvm was released, gcc typically produced faster binaries but llvm optimizations were easier to understand. Since then, both have evolved and I haven't tried to catch up.
Bottom line: having two back-ends for rust or any other language is good. Among other things, it's a good way to check for bugs within an implementation of the compiler, it can be used to increase the chances of finding subtle bugs in safety-critical code, etc.
The most recent restrict bug the rustc developers found (which made they disable restrict again) was found in both LLVM and GCC (they made a C reproducer, so they could test in both). See: https://github.com/rust-lang/rust/issues/54878 (rustc) https://bugs.llvm.org/show_bug.cgi?id=39282 (LLVM) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609 (GCC).
I even filed a version of it myself:
I'm actually surprised that Rust enabled noalias usage with this known outstanding issue. When I worked on Rust years ago, it was definitely common knowledge on the compiler "team" that this was broken.
I'm equally surprised that GCC had that bug, since their pointer aliasing model is equipped to correctly handle this situation (and is why they were able to fix it quickly).
And the number of architectures by LLVM:
GCC supports vastly more targets.
That is my experience too.
GCC for code with high level of nesting, meaning high potential for inlining (typically C++), is close to unbeatable. Including even compared Highly optimised compilers like Intel ICC.
LLVM's IR is not stable by design. [1, 2]
> while GCC refuses to do so over the decades for political and strategic reasons.
That was a long time ago. Since GCC 4.5 (released in 2010) GCC supports external plugins. [3,4] These plugins, like the rest of GCC, use GENERIC and GIMPLE as their IR.