More Than 100 Rust Patches Merged Today For GCC 13

[phoronix]

Phoronix: More Than 100 Rust Patches Merged Today For GCC 13

Merged back in December was the initial GCC Rust front-end "gccrs" for the GCC 13 compiler that will be released as stable within the next month or two. Squeezing today into the GCC 13 code-base is an additional 103 patches for this Rust front-end...

https://www.phoronix.com/news/GCCRS-103-More-Patches-Land

[scottishduck]

I can’t ever see this compiler being used instead of the official LLVM-based one. Seems like a huge waste of effort.

[You-]

Good job.

Even if not used, having support in GCC is important IMO. GCC also supports architectures that LLVM doesnt and where to use rust you will need to use GCC (either via this frontend, or via the backend approach that is also being worked on).

However I do think this will be used. Especially on linux, GCC is mostly the preferred project to use.

[Developer12]

Sorry for the amount of commits pushed, but since the project is starting to receive more and more contributions, we thought it was important for GCC contributors to hack on the most recent version of the frontend as well.

This is only going to get worse. The rust community heavily relies upon the shipping of nightly builds of rustc, with all of their attendant in-development features.

There is absolutely no way that this GCC frontend will ever meaningfully keep up. The best that this frontend might do is match whatever the last rustc official release was, which is woefully out of date for a lot of rust use. The rust for linux effort itself has relied on a lot of these unstable features, and they're far from the only ones. Most large rust codebases rely on them in some shape or form while waiting for the features to be stabilized in an official release.

The correct solution is to make use of rustc, employ GCC as a codegen backend, and let both projects focus on what they're good at. Rustc handles the churn of new features well through their nightly builds, and GCC can worry about turning IR into machine code for various platforms LLVM doesn't yet support.

Or, maybe this is all 100% academic because most if not all of the architectures GCC supports but LLVM doesn't are continually slated to be dropped from the kernel anyway.

[darkoverlordofdata]

My guess is that a rust front end for gcc is not intended for the rust community. It’s for GNU purists such as the Trisquel distro. Good for them.

[kpedersen]

I can’t ever see this compiler being used instead of the official LLVM-based one. Seems like a huge waste of effort.

They used to say that about GNU and Linux in general. They also used to say that about LLVM / clang too.

More implementations means more flexibility. It is never a waste.

[oiaohm]

I can’t ever see this compiler being used instead of the official LLVM-based one. Seems like a huge waste of effort.

I can see this compiler possible being used. You cannot mix llvm generated objects with gcc generated objects into a single generated binary and have perfect stability.

One big alarm bell for something like the Linux kernel is that llvm and gcc do 128 bit integer processing differently. Yes the Linux kernel does use 128bit intigers in different sections of it code base yes these are not exported across syscalls due to the instability.

This is only going to get worse. The rust community heavily relies upon the shipping of nightly builds of rustc, with all of their attendant in-development features.

There is absolutely no way that this GCC frontend will ever meaningfully keep up. The best that this frontend might do is match whatever the last rustc official release was, which is woefully out of date for a lot of rust use. The rust for linux effort itself has relied on a lot of these unstable features, and they're far from the only ones. Most large rust codebases rely on them in some shape or form while waiting for the features to be stabilized in an official release.

One mistake here Linux kernel does not use the latests and greatest C version. Like the kernel is C11 and the current c standard version is C17. We can expect the same with rust support in the Linux kernel that it will be for some selected old version.

]The correct solution is to make use of rustc, employ GCC as a codegen backend, and let both projects focus on what they're good at. Rustc handles the churn of new features well through their nightly builds, and GCC can worry about turning IR into machine code for various platforms LLVM doesn't yet support

This has it own problem. rustc_codegen_gcc in rustc uses libgccjit,

https://github.com/rust-lang/rustc_codegen_gcc

Yes this end up at times needing custom patches applied to gcc so it works. Now this bring Pandora box of gcc and rustc needing to be in sync with each other. Part of that pandora box is what todo if the patches that make libgccjit work for rustc_codegen_gcc happens to break something else about the gcc. Fully upstream has advantage of being synced here.

My guess is that a rust front end for gcc is not intended for the rust community. It’s for GNU purists such as the Trisquel distro. Good for them.

I wish it was some special case. But its not. Like it or not llvm and gcc generated object files are in fact at incompatible with each other to be linked into a single executable. Also it gets worse gcc and llvm both if you uses object files made by multi versions in single executable bad things happen at times. llvm version x made object with llvm version y made object equals some really bad behavour happens is documented over and over again and you find the same on the gcc side.

So a gcc version of rust will be required for rust to be usable in more places. This version need to be able to stay in sync with gcc releases.

There are also the number of implementation bugs proven in llvm and gcc by Linux kernel adding llvm as a second compiler.

There does need to be at least 2 implementations of rust to make sure rust documentation on how the standard works is some what valid.

How rust language support gcc is a problem that does need solving. Linux kernel does make this harder with the Linux kernel using gcc plugin system to run processing to validate functionality.

Linux kernel requirements of rust will not be latest and greatest rust version but is correctly functional gcc support.

There is something else to consider. Gcc was able to move it core from C to C++ because C++ was going to work out better than C and C++ was a language that gcc itself directly supported. Gcc with mainlined rust complier even if it a old version would allow rust to be used in gcc for core gcc parts in time.

Rust is meant to be this safe language right depending on llvm that is C++ means it still depending on questionable C++ code.

Mainline into gcc long term gives chance of pure rust back-end. LLVM will be resistant to having rust in it back end due to it not having rust mainline either.

[darcagn]

I can’t ever see this compiler being used instead of the official LLVM-based one. Seems like a huge waste of effort.

Speak for yourself… My target platform of choice isn’t available on LLVM.

[CommunityMember]

Good job. However I do think this will be used. Especially on linux, GCC is mostly the preferred project to use.

Actually, linux kernels on the majority of the shipped and running platforms appear to be compiled using llvm (much of the android ecosystem, and a bunch of the hyperscalers based on their public contributions and comments regarding using features that only llvm support, although gcc does play catchup over time).

That is not to say having another compiler is not a good thing, for it is, to avoid monoculture, but playing catchup is not a good look (and may not be sustainable in the long term).

[oiaohm]

Actually, linux kernels on the majority of the shipped and running platforms appear to be compiled using llvm (much of the android ecosystem, and a bunch of the hyperscalers based on their public contributions and comments regarding using features that only llvm support, although gcc does play catchup over time).

That is not to say having another compiler is not a good thing, for it is, to avoid monoculture, but playing catchup is not a good look (and may not be sustainable in the long term).

https://stackoverflow.com/questions/...e-are-they-now

This gets into a very strange location with Android. Arm themselves support and recommend using gcc not LLVM. There are lot of devices like routers and the like that are in fact gcc based. LLVM and GCC usage with Linux neither is in a dominate position. Gcc is used due to its tooling in the development process of the Linux kernel to look at code quality.

https://discuss.96boards.org/t/fails-to-build-the-kernel-prebuilts-after-gcc-got-deprecated/9422

There are many arm boards that will not work with a LLVM built kernel. Yes many android phones as well that do not work with LLVM built kernel. Google is stubborn here wanting the kernel made with LLVM even if the result is total failure for particular devices.