The Current State Of GCC 13's Rust Language Front-End

[phoronix]

Phoronix: The Current State Of GCC 13's Rust Language Front-End

Arthur Cohen with Embecosm presented at the FOSDEM developer conference earlier this month on gccrs, the ongoing effort to provide a Rust language front-end to the GCC compiler. While the GCC Rust front-end has been merged for the upcoming GCC 13 release, it's not yet in a state that will really be usable to most Rust developers yet as an alternative to Rust's official LLVM-based compiler...

https://www.phoronix.com/news/GCC-13-Rust-Front-End-State

[Developer12]

https://twitter.com/gnutools/status/1600133864449400834

https://lwn.net/Articles/917300/

Reminder that the sole reason this exists is to support grsecurity's continued use of proprietary GCC plugins. Nobody in favour of free software should be in support of this frontend's development. Hell, grsecurity isn't that well liked in the general kernel development community either. https://www.spinics.net/lists/kernel/msg2540934.html

Not only that, but this is simply a bad way to bring rust to GCC. The real way to do it is rustc_codegen_gcc, where the official rustc compiler emits code for GCC's consumption. This works out better for rust, it works out better for GCC, it works out better for everyone. Except grsecurity and their proprietary bullshit.

The entire rust community relies heavily on nightly builds of the rustc compiler. Stabilized features of the language, which have gone through enormous testing and refinement, find their way into official releases of rustc. However, a sizeable portion of projects make use of unstable features, which have gone through the proposal and acceptance process but are still considered unstable. These ship in nightly builds and can/will change at any time in response to feedback from actual usage. The rust for linux effort has made use of lots of these features in the past, though there has been a push to get many of them through stabilisation, and it's not unique in this.

Now why would/should GCC want do deal with all that churn? We're talking about continuous changes to scores of features, all being shipped out on a daily basis to every user of of the compiler. Rustc accomplishes this using rustup. GCC and various distros have no such procedures or tooling, and it would be a huge burden for GCC to try to keep up. The alternative is a perpetually broken, out of date compiler frontend that's useless to many people.

Instead GCC should really take the easy way out here, shipping a stable GCC compiler that consumes code in a stable format from the rapidly changing rustc. Let GCC specialize in targeting all the platforms it does and let rustc focus on the evolution of the language.

[nanonyme]

https://twitter.com/gnutools/status/1600133864449400834

https://lwn.net/Articles/917300/

Reminder that the sole reason this exists is to support grsecurity's continued use of proprietary GCC plugins. Nobody in favour of free software should be in support of this frontend's development. Hell, grsecurity isn't that well liked in the general kernel development community either. https://www.spinics.net/lists/kernel/msg2540934.html

Not only that, but this is simply a bad way to bring rust to GCC. The real way to do it is rustc_codegen_gcc, where the official rustc compiler emits code for GCC's consumption. This works out better for rust, it works out better for GCC, it works out better for everyone. Except grsecurity and their proprietary bullshit.

The entire rust community relies heavily on nightly builds of the rustc compiler. Stabilized features of the language, which have gone through enormous testing and refinement, find their way into official releases of rustc. However, a sizeable portion of projects make use of unstable features, which have gone through the proposal and acceptance process but are still considered unstable. These ship in nightly builds and can/will change at any time in response to feedback from actual usage. The rust for linux effort has made use of lots of these features in the past, though there has been a push to get many of them through stabilisation, and it's not unique in this.

Now why would/should GCC want do deal with all that churn? We're talking about continuous changes to scores of features, all being shipped out on a daily basis to every user of of the compiler. Rustc accomplishes this using rustup. GCC and various distros have no such procedures or tooling, and it would be a huge burden for GCC to try to keep up. The alternative is a perpetually broken, out of date compiler frontend that's useless to many people.

Instead GCC should really take the easy way out here, shipping a stable GCC compiler that consumes code in a stable format from the rapidly changing rustc. Let GCC specialize in targeting all the platforms it does and let rustc focus on the evolution of the language.

As someone routinely building Rust, I wholeheartedly disagree with that idea of using upstream rustc. Rust is currently a PITA to build without upstream binaries, much more so than Go which can be built with gccgo. In some bright future Rust may become as distro-friendly language as Go.

[RahulSundaram]

https://twitter.com/gnutools/status/1600133864449400834

https://lwn.net/Articles/917300/

Reminder that the sole reason this exists is to support grsecurity's continued use of proprietary GCC plugins.

You have repeated this claim in many places and it is simply not true. Let's read the press release you linked to from the LWN comment

https://opensrcsec.com/open_source_security_announces_rust_gcc_funding

As the source of the GCC plugin infrastructure in the Linux kernel and nearly all of the GCC plugins adapted for inclusion in the upstream Linux kernel, we too immediately spotted the importance of this problem and set out to ensure both those plugins as well as the security features built-in to GCC itself are able to instrument code from all languages supported by the Linux kernel with compatible and consistent security properties.

In other words, they are talking about open source GCC plugins included within the linux kernel.

[Ironmask]

https://twitter.com/gnutools/status/1600133864449400834

https://lwn.net/Articles/917300/

Reminder that the sole reason this exists is to support grsecurity's continued use of proprietary GCC plugins. Nobody in favour of free software should be in support of this frontend's development. Hell, grsecurity isn't that well liked in the general kernel development community either. https://www.spinics.net/lists/kernel/msg2540934.html

Not only that, but this is simply a bad way to bring rust to GCC. The real way to do it is rustc_codegen_gcc, where the official rustc compiler emits code for GCC's consumption. This works out better for rust, it works out better for GCC, it works out better for everyone. Except grsecurity and their proprietary bullshit.

The entire rust community relies heavily on nightly builds of the rustc compiler. Stabilized features of the language, which have gone through enormous testing and refinement, find their way into official releases of rustc. However, a sizeable portion of projects make use of unstable features, which have gone through the proposal and acceptance process but are still considered unstable. These ship in nightly builds and can/will change at any time in response to feedback from actual usage. The rust for linux effort has made use of lots of these features in the past, though there has been a push to get many of them through stabilisation, and it's not unique in this.

Now why would/should GCC want do deal with all that churn? We're talking about continuous changes to scores of features, all being shipped out on a daily basis to every user of of the compiler. Rustc accomplishes this using rustup. GCC and various distros have no such procedures or tooling, and it would be a huge burden for GCC to try to keep up. The alternative is a perpetually broken, out of date compiler frontend that's useless to many people.

Instead GCC should really take the easy way out here, shipping a stable GCC compiler that consumes code in a stable format from the rapidly changing rustc. Let GCC specialize in targeting all the platforms it does and let rustc focus on the evolution of the language.

It seems the sources you linked are primarily outraged because they're part of the FSF cult and simply dislike LLVM because it isn't GCC. Your other primary argument is because someone you don't like is funding it. You don't like this person because they want to make software without showing you the source code, so you feel like you need to "cancel" the project they're funding because you feel like politics are more important than practical software alternatives. The rest of your arguments, while semi-valid, feel like excuses and axillary justifications for your initial outrage stemming from being overtly concerned about the petty politics of a software cult over practical software engineering.
I think you should probably go find a project to actually contribute to instead of acting like a deranged cultist who needs to burn anything even remotely related to people who don't wish to spread St. IGNUtius' holy message about stoning those who refuse to publish their source code. Let people create alternative projects and let competition work everything out.

[EphemeralEft]

I guess the real question is what's worse: constantly playing catch-up with Rust or constantly playing catch-up with GNU C extensions?

[cj.wijtmans]

When GNU EEEs you but you never expected it. Good thing though nothing good comes from centralized communism rust.

[ssokolow]

I guess the real question is what's worse: constantly playing catch-up with Rust or constantly playing catch-up with GNU C extensions?

Is there something I'm missing? The other project, rust_codegen_gcc, is putting the official rustc frontend on top of GCC as a backend, so why would it have to make that choice?

(And yes, alternative backends is an officially supported use for rustc. They're also working on a Cranelift backend so debug build times aren't being held back by LLVM which they intend to eventually make the official default for debug builds, similar to how they're working to squash regressions so they can switch from GNU's ld.bfd to LLVM's lld as the default linker to roughly halve the time the linking phase takes.)

[Volta]

I think you should probably go find a project to actually contribute to instead of acting like a deranged cultist who needs to burn anything even remotely related to people who don't wish to spread St. IGNUtius' holy message about stoning those who refuse to publish their source code. Let people create alternative projects and let competition work everything out.

And they would be right about this. However, it seems it's not the case here and not everyone sees llvm/clang strumpet way as 'practical software engineering'. It's you who brings this down to cult level.

[timofonic]

Rust seems an interesting programming language.
It's not perfect as many say because everything has it's drawnbacks, but it has quite a lot of potential. Here are my scare points:
- Compiler monoculture. It seems everything outside llvm/rustc is evil.
- Cult/Sect attitude. Quite related to compiler monoculture but also stuff such as Rewriting the Entire World in Rust(TM).

If Rust gets at least full mature GCC support and formal specifications, I will see it as a more serious programming language rather than an experiment.