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

21–30 of 135 posts

Re: Rust front-end merged in GCC trunk

#21

Post by GrayShade »

wofo wrote: post #9
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 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.

That's rather rustc_codegen_gcc. gcc-rs is more for people who don't like LLVM and/or Rust.

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

Re: Rust front-end merged in GCC trunk

#22

Post by elsjaako »

viraptor wrote: post #13
elsjaako wrote: post #10

Earlier quoted context omitted.

AVR (for example, old Arduino boards) and xtensa (like esp32 developer boards) are the only ones I know of. Most of the desktop OS platforms are supported by both.

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

I didn't know that!

Re: Rust front-end merged in GCC trunk

#23

Post by hawk_ »

wofo wrote: post #9
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 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.

No borrow checking is effectively a dialect of Rust?

Re: Rust front-end merged in GCC trunk

#25

Post by pantalaimon »

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.

Espressif has forks of everything (OpenOCD, GDB, GCC) that they never mainline and that just become outdated as they release new chips.

The latest xtensa-esp8266-elf-gcc is version 5.2

Re: Rust front-end merged in GCC trunk

#26

Post by pantalaimon »

cogman10 wrote: post #12
scaredginger wrote: post #6

Earlier quoted context omitted.

Out of curiosity, what can GCC's backend generate that LLVM can't?

It's pretty frequent that embedded chips will have patched versions of GCC in their toolkit.

But only the more 'exotic' architectures. Everything ARM works fine with upstream GCC.

Re: Rust front-end merged in GCC trunk

#27

Post by Myrmornis »

wofo wrote: post #9
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 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?

Re: Rust front-end merged in GCC trunk

#28

Post by kibwen »

hawk_ wrote: post #23
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.

No borrow checking is effectively a dialect of Rust?

Without a borrow checker, at best it can be considered a code generator for pre-certified Rust source code. Possibly useful, but you'd still need to have rustc in the loop.

Re: Rust front-end merged in GCC trunk

#29

Post by rapsey »

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?

Borrow checker is compile time. There is no reason to have multiple implementations.

Re: Rust front-end merged in GCC trunk

#30

Post by pjmlp »

bonzini wrote: post #18
pabs3 wrote: post #7

Earlier quoted context omitted.

What happened to gcj?

Since there is now OpenJDK, there was no reason to keep working on it, and both GCJ and the associated class libraries didn't follow the evolution in the Java language. In the beginning GCJ became only an ahead-of-time bytecode compiler, with the Java->bytecode translation done using ecj; but ultimately there was no reason to keep it around at all and it was deleted in GCC 7.

Ahead of time native code compiler.

It was kept around for a long time after everyone went to OpenJDK, because it was the only project with certain unit tests for GCC code paths, when that was eventually sorted out, it was when they dropped it.

Post reply on HN