Does this mean I can now finally generate object files from .rs sources and link them myself?
That is one of the things that rustc is severely lacking.
Rust front-end merged in GCC trunk
11–20 of 135 posts
Re: Rust front-end merged in GCC trunk
#12Re: Rust front-end merged in GCC trunk
#13Earlier quoted context omitted.
Out of curiosity, what can GCC's backend generate that LLVM can't?
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?
Re: Rust front-end merged in GCC trunk
#14Earlier quoted context omitted.
More architectures supported at least. Now Rust can really be used anywhere C is used
Out of curiosity, what can GCC's backend generate that LLVM can't?
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 archs, though some of them might be due to rustc or bringup bugs (e.g. m68k is supposedly supported by llvm and rustc).
Then there’s embedded, on the more open side LLVM is slowly gaining ground but there’s also less open ecosystems where customising / forking gcc is pretty standard historically, and there’s not much LLVM can do.
Re: Rust front-end merged in GCC trunk
#15Does this mean I can now finally generate object files from .rs sources and link them myself? That is one of the things that rustc is severely lacking.
Is that not what "rustc --emit=obj" does now?
Re: Rust front-end merged in GCC trunk
#16Re: Rust front-end merged in GCC trunk
#17Earlier 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?
Also while ESP32 has not been mainlined (I think), Espressif has both an llvm and a rustc fork.
Re: Rust front-end merged in GCC trunk
#18What 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)
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.
Re: Rust front-end merged in GCC trunk
#19Earlier quoted context omitted.
Out of curiosity, what can GCC's backend generate that LLVM can't?
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.
Re: Rust front-end merged in GCC trunk
#20Earlier 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.
I disagree, but that aside I think the big motivator was embedded support. The reality is what OP said: companies fork GCC.