Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust front-end merged in GCC trunk

gcc.gnu.org

Post reply on HN
Print view View original

31–40 of 135 posts

Re: Rust front-end merged in GCC trunk

#31

Post by tuetuopay »

Myrmornis wrote: post #27
wofo wrote: post #9

Earlier quoted context omitted.

I think this is more of an attempt of making Rust compilable on platforms not supported by LLVM, not an attempt to replace the existing compiler. The GCC frontend, for instance, does not implement the borrow checker, so you should only use it to compile Rust code you know is correct according to the official Rust compiler.

It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?

This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.

Re: Rust front-end merged in GCC trunk

#32

Post by bombolo »

zozbot234 wrote: post #19
masklinn wrote: post #14

Earlier quoted context omitted.

Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. The LLVM backends which do exist for such also tend to have been exercised less and thus me more buggy (I think PPC/spe had a fair amount of issues there but it might have gotten better). You can see something of a summary over on https://builds.Debian.org/status/package.php?p=rustc&suite=s... the BD-Uninstallable entries are unsupported ar…

> Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. If there are people who care about these historical architectures, they can do the work to maintain them in LLVM. That's how m68k support was added.

> If there are people who care about these historical architectures, they can do the work to maintain them in LLVM.

Or they can decide to use an existing compiler that already works.

Re: Rust front-end merged in GCC trunk

#33

Post by skitter »

rapsey wrote: post #4
rwmj wrote: post #2

What are the practical implications of this? Could cargo call GCC? Or would it be like gcj and allow compiled rust libraries & binaries to be distributed? (at least in theory, gcj didn't work out well)

More architectures supported at least. Now Rust can really be used anywhere C is used

You don't need to write an new frontend for that, just add libgccjit as a backend for rustc.

Re: Rust front-end merged in GCC trunk

#34

Post by GrayShade »

tuetuopay wrote: post #31
Myrmornis wrote: post #27

Earlier quoted context omitted.

It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?

This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.

Why not use this instead?

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

Re: Rust front-end merged in GCC trunk

#35

Post by sseagull »

hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

I’ve come to the conclusion that fragmentation is inevitable as a language gets popular.

People think differently, have different ideas for how to do things, need it to work for their particular use case, etc. Fragmentation and bloat are a result.

I am willing to bet it will happen rust as it gets used more and more. Then the treadmill will start again with a new language.

(Sorry if that’s jaded. I’ve been fighting with python build systems lately. What a nightmare)

Re: Rust front-end merged in GCC trunk

#36

Post by JoshTriplett »

hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

The gccrs developers have talked at length with Rust developers towards the same aim: they don't want to create fragmentation either. Among other things, the gccrs developers have said in multiple places both public and private:

- They aren't going to fork or extend the language; they'll work with the normal Rust language evolution process.

- They're treating rustc as the reference for correct Rust. This doesn't mean there can't be bugs in either rustc or gccrs, and rustc will deeply appreciate bug reports found through this level of inspection of its behavior, but nonetheless this is a stated goal of the gccrs folks.

- They plan to explicitly provide messaging, potentially even in compiler error messages, to the effect of "if gccrs doesn't compile a crate that does compile on rustc, that's a bug in gccrs, not a bug in that crate; do not report it as a bug in that crate or ask crate developers to work around gccrs limitations".

So, I think the gccrs folks are doing everything they can to avoid fragmentation, short of the project not existing at all.

Re: Rust front-end merged in GCC trunk

#37

Post by skitter »

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work.

¹https://github.com/rust-lang/rust/tree/master/compiler/rustc...

Re: Rust front-end merged in GCC trunk

#38

Post by jeroenhd »

zozbot234 wrote: post #19
masklinn wrote: post #14

Earlier quoted context omitted.

Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. The LLVM backends which do exist for such also tend to have been exercised less and thus me more buggy (I think PPC/spe had a fair amount of issues there but it might have gotten better). You can see something of a summary over on https://builds.Debian.org/status/package.php?p=rustc&suite=s... the BD-Uninstallable entries are unsupported ar…

> Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. If there are people who care about these historical architectures, they can do the work to maintain them in LLVM. That's how m68k support was added.

Some of those older architectures are supported by the Linux kernel, which is adopting Rust. Giving GCC the ability to compile Rust code maintains support for those platforms as the percentage of Rust in the kernel grows.

There are also embedded applications, of course; plenty of crappy manufacturers still give you a GCC fork as your only compiler for their dedicated hardware. The ability to get Rust hooked into those compilers can help keep the ecosystem up to date.

Even companies maintaining their own software sometimes take a long time to add support to LLVM. Take for example Espressif's Xtensa fork that is only now starting to get merged (if https://discourse.llvm.org/t/rfc-request-for-upstream-tensil... is to be believed). Many patches are still waiting for review, so it'll be a while until LLVM finally supports Xtensa (and with it microcontrollers such as the ESP32). GCC has had Xtensa support for ages (Github lists xtensa.h going back all the way to 2002) and I doubt Espressif is the only company in this position.

"Just do the work" sounds easy but that work can take years. Getting modern Linux versions to compile may not be enough to drive companies to put in the effort; many may prefer to simply never update their kernels past the current LTS version again.

Adding a frontend to GCC works around this problem quite efficiently. It also makes it easier to port existing code to these platforms; sure, the lack of a borrow checker drops all guarantees Rust has been designed to provide, but if you're not writing any code, you don't need those anyway.

Re: Rust front-end merged in GCC trunk

#39

Post by jeroenhd »

masklinn wrote: post #17
viraptor wrote: post #13

Earlier quoted context omitted.

AVR should be working these days https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ... Unless you mean some specific chips?

Also while ESP32 has not been mainlined (I think), Espressif has both an llvm and a rustc fork.

Their first patches are in the process of being merged: https://discourse.llvm.org/t/rfc-request-for-upstream-tensil...

Re: Rust front-end merged in GCC trunk

#40

Post by whyarewheher »

skitter wrote: post #37

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work. ¹ https://github.com/rust-lang/rust/tree/master/compiler/rustc...

Why not do it? There are lots of reasons to have multiple implementations of a language, one of them being gcc is much easier to bootstrap than rustc
Post reply on HN