GCC Rust Compiler "gccrs" Sees ~900 New Patches Upstreamed For GCC 14

[slanterns]

Because of official (to be honest, the only way) to install rust:

is pathetic and miserable.

I don't think anarki2 is talking about 'an official installation.' What he/she means is just rustc rarher than gccrs.

[oleid]

because there is no linking in libgccjit. its a jit library... they are literally mutually exclusive.

It doesn't have to link. In such a set-up you'd link with gcc anyway (called e.g. via rustc or your favourite build system). Libgccjit would merely create .o files with gimpl code.

[oleid]

Because of official (to be honest, the only way) to install rust:

is pathetic and miserable.

You see these types of installations for various things more often in the wild than you might think.
Another prominent example is platformio.

Luckily at least on Linux distributions which come with rustup, there is no need to download shell scripts.
Just install the latest version of the compiler with your distribution's rustup command (see distributions listed below).
Or use the rust compiler which comes with your distribution if it fits your use case (e.g. Arch, Nix, Gentoo, OpenSUSE)

[moltonel]

rustc using the GCC libgccjit codegen doesn't work cross-compiling to SuperH except with 3rd party patches that haven't worked in months.

Fair point (even if cherry-picked).

But GCCRS works out of the box.

Big no. Gccrs doesn't even fully support string formatting yet, they've only recently managed to compile the standard hello world. And it's naive to think that gccrs will magically support of all the arches that the gcc codegen supports: there's work needed in the frontend, whether it's rustc or gccrs.

rustc_codegen_gcc lacks polish, gccrs lack basic functionality.

[moltonel]

Do they want to include Rust code inside GCC?

Gccrs uses the same standard library as Rustc. No patch, just pegged at the version they are trying to support (which is over 3 years old at this stage). That's great for compatibility, and will save them time in the long run (though it's slowing them down while they're still implementing basic functionality). They also use some libraries from the Rust ecosystem.

[moltonel]

There are targets that GCC supports that the official compiler doesn't support.

More hardware support. GCC supports much more targets than LLVM currently can.

That still doesn't explain why you'd want gccrs instead of rustc with its gcc backend.

[moltonel]

I get so confused about all of the various components here

It doesn't help when the phoronix article uses misleading terms like "the LLVM-based rustc official Rust compiler".

rustc_codegen_gcc: Allows GCC to be used with rustc, and LLVM by extension (I think!) Not sure what direction things pass through, but sounds like ultimately you get the greater architectural coverage of GCC, generating bytecode (or something like that) than can then be consumed by rustc/LLVM. So you ultimate get to use the offical Rust compiler.

Not quite. The rustc compiler is a "frontend" (the part that understands the rust language), and it supports various "backends" (the part that can generate machine code). The standard backend for rustc uses LLVM (hence why many people think of rustc as llvm-based), but there is also a backend that uses gcc (that's rustc_codegen_gcc), a self-standing backend (cranelift), and experimental backends targetting the .net vm and some graphic cards. It's a very neat and flexible system.

[moltonel]

because there is no linking in libgccjit. its a jit library... they are literally mutually exclusive.

Despite its name, libgccjit is not mainly a jit library, it generates fully AOT-compiled code, that needs to be linked like normal. Rustc_codegen_gcc enabled LTO for rust code a few months ago. If there are still some bugs when LTO'ing C and Rust code compiled by gcc (source ?), it would just be a technical hurdle, not a fundamental limitation.

[oleid]

That still doesn't explain why you'd want gccrs instead of rustc with its gcc backend.

Gccrs would certainly help with bootstrapping rustc.

[darcagn]

Fair point (even if cherry-picked).

While it might be a picked cherry to you, it's my actual use case, and the reason I'm interested in either project at all, so it means the world to me.

Big no. Gccrs doesn't even fully support string formatting yet, they've only recently managed to compile the standard hello world. And it's naive to think that gccrs will magically support of all the arches that the gcc codegen supports: there's work needed in the frontend, whether it's rustc or gccrs.

rustc_codegen_gcc lacks polish, gccrs lack basic functionality.

By "works out of the box" I meant that I can build a SuperH cross compiler with zero patches or adjustments with the GCC-RS git repo. It might only support 1% of the actual language, but that 1% builds and works just fine. I've written code using it and so has a colleague of mine. It's bastardized pseudo-Rust, but it's a starting point for our projects.

rustc_codegen_gcc doesn't build for me. That's not a slight or an insult, it's just a fact. I don't have a horse in this race, either way, if I can compile Rust to SuperH, I'm very happy, so if I wake up tomorrow and rustc_codegen_gcc works 100% then I'll use it. In fact, when I get time I might even try to solve the problem myself and contribute back. But in the mean time I've read many comments questioning why the project that works for me should exist when the project that doesn't work for me exists, so I give my opinion as probably one of the few in this thread who have actually tried to work with both gccrs and rustc_codegen_gcc.

If you bothered to quote my entire post (where I wrote "Of course GCCRS is way behind in features, it's still super early on for it unfortunately.") then we we actually agree on this.