15 ms·

Rust front-end merged in GCC trunk

158 points by pratk 4y ago

rwmj 4y ago
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)
- Conan_Kudo 4y ago
  Cargo could call gcc-rs instead of rustc.
  - kangalioo 4y ago
    The point of GCCRS over rustc_codegen_gcc is to make Rust easier integrateable into other projects and build systems. If you use Cargo anyways, you're much better off using rustc_codegen_gcc
- rapsey 4y ago
  More architectures supported at least. Now Rust can really be used anywhere C is used
  - scaredginger 4y ago
    Out of curiosity, what can GCC's backend generate that LLVM can't?
    - cogman10 4y ago
      It's pretty frequent that embedded chips will have patched versions of GCC in their toolkit.
      - pantalaimon 4y ago
        But only the more 'exotic' architectures. Everything ARM works fine with upstream GCC.
    - elsjaako 4y ago
      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.
      - viraptor 4y ago
        AVR should be working these days https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/AVR https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ... Unless you mean some specific chips?
        masklinn 4y ago
        Also while ESP32 has not been mainlined (I think), Espressif has both an llvm and a rustc fork.
        pantalaimon 4y ago
        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
        jeroenhd 4y ago
        Their first patches are in the process of being merged: https://discourse.llvm.org/t/rfc-request-for-upstream-tensilica-xtensa-esp32-backend/65355 https://discourse.llvm.org/t/rfc-request-for-upstream-tensil...
        elsjaako 4y ago
        I didn't know that!
    - masklinn 4y ago
      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=sid 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.
      - zozbot234 4y ago
        > 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.
        camgunz 4y ago
        I disagree, but that aside I think the big motivator was embedded support. The reality is what OP said: companies fork GCC.
        bombolo 4y ago
        > 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.
        jeroenhd 4y ago
        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-tensilica-xtensa-esp32-backend/65355/5 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.
  - skitter 4y ago
    You don't need to write an new frontend for that, just add libgccjit as a backend for rustc.
    - kangalioo 4y ago
      Which has been done, and I'm really sad how that effort has been overshadowed hard by GCCRS, when the latter is much more niche in its use case
  - MaxBarraclough 4y ago
    Not so, there some obscure hardware platforms with C compilers but which are unsupported by GCC. GCC has no official backend for PIC or Z80, for instance. Non-standard C-like languages are used in computer graphics and GPU computing (OpenGL, Direct3D, OpenCL), but strictly speaking they don't count as C.
- pabs3 4y ago
  There is also a project for rustc to use GCC instead of LLVM for codegen. https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc
- pabs3 4y ago
  What happened to gcj?
  - e12e 4y ago
    It grew stale(?) and was dropped in gcc 7.
  - bonzini 4y ago
    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.
    - pjmlp 4y ago
      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.
      - bonzini 4y ago
        I meant it compiled bytecode to native ahead of time. There was also a source to native part which was removed first.
hardware2win 4y ago
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
- wofo 4y ago
  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.
  - GrayShade 4y ago
    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 https://github.com/rust-lang/rustc_codegen_gcc
    - masklinn 4y ago
      A rust implementation for people who don’t like rust seems like a strange take.
      - cstrahan 4y ago
        Not too strange. Imagine the reverse: a C compiler written in Rust. There is an awful lot of software in C that I want to use, but I really dislike C itself. If I found some deficiency in C compilers and felt the need to write my own, I certainly would prefer to write it in Rust. It would be a C implementation for people who don't like C.
  - hawk_ 4y ago
    No borrow checking is effectively a dialect of Rust?
sp1rit 4y ago
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.
- viraptor 4y ago
  Is that not what "rustc --emit=obj" does now?
- stingraycharles 4y ago
  Out of curiosity, why would you need this?
  - hgs3 4y ago
    You're basically asking why you'd want object files. They're a container of (usually) relocatable machine code. You can inspect or modify them with nm [1] or objcopy [2]. You can link them with object files generated from other programming languages to mix languages. Maybe you have a custom linker or environment that requires you to convert an ELF or COFF object file to some custom variant. There are lots of reasons. [1] https://linux.die.net/man/1/nm https://linux.die.net/man/1/nm [2] https://linux.die.net/man/1/objcopy https://linux.die.net/man/1/objcopy
- deleted 4y ago
  [deleted]
skitter 4y ago
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_codegen_gcc https://github.com/rust-lang/rust/tree/master/compiler/rustc...
- whyarewheher 4y ago
  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
  - skitter 4y ago
    rustc got bootstrapped already, so download it. If you want to run the compiler itself on a new architecture, cross-compile. If you still decide to bootstrap it again, that's something that will only need to be done once. And even in that case, you can use the second implementation that already exists, mrustc.
- kangalioo 4y ago
  I've wondered about this for ages and now know: the people who work on GCCRS wouldn't work on rustc_codegen_gcc for one reason or another (familiarity, culture, personal ideals...?). So GCCRS is not "eating away" at available bandwidth and there's no reason not to let GCCRS developers do their thing, even if rustc_codegen_gcc is a more straightforward way of achieving most goals
- IshKebab 4y ago
  It's probably not hugely useful from a "I want to compile this Rust code" point of view but I imagine it will at least help iron out ambiguities and bugs in the various specs people are working on. I think there's at least MiniRust and the Ferrocene Language Specification: https://www.youtube.com/watch?v=eFpHadbv34I https://www.youtube.com/watch?v=eFpHadbv34I https://spec.ferrocene.dev/ https://spec.ferrocene.dev/
c0l0 4y ago
Probably a dumb question, but I'd really like to know if this somehow affects/improves Rust's support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?
- mlindner 4y ago
  I would naively assume that it doesn't affect it at all. Compiling with GCC doesn't magically make dynamic linking better. The limitation in dynamic linking is an element of language design. I'd also note that any Rust you compile with GCC probably shouldn't be dynamically linked with Rust code compiled with rustc.
rurban 4y ago
Their base62 implementation really looks unreviewed. A static 64 byte array for 62 bytes...

158 points by pratk 4y ago

rwmj 4y ago

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)

Conan_Kudo 4y ago
Cargo could call gcc-rs instead of rustc.
- kangalioo 4y ago
  The point of GCCRS over rustc_codegen_gcc is to make Rust easier integrateable into other projects and build systems. If you use Cargo anyways, you're much better off using rustc_codegen_gcc
rapsey 4y ago
More architectures supported at least. Now Rust can really be used anywhere C is used
- scaredginger 4y ago
  Out of curiosity, what can GCC's backend generate that LLVM can't?
  - cogman10 4y ago
    It's pretty frequent that embedded chips will have patched versions of GCC in their toolkit.
    - pantalaimon 4y ago
      But only the more 'exotic' architectures. Everything ARM works fine with upstream GCC.
  - elsjaako 4y ago
    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.
    - viraptor 4y ago
      AVR should be working these days https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/AVR https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ... Unless you mean some specific chips?
      - masklinn 4y ago
        Also while ESP32 has not been mainlined (I think), Espressif has both an llvm and a rustc fork.
        pantalaimon 4y ago
        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
        jeroenhd 4y ago
        Their first patches are in the process of being merged: https://discourse.llvm.org/t/rfc-request-for-upstream-tensilica-xtensa-esp32-backend/65355 https://discourse.llvm.org/t/rfc-request-for-upstream-tensil...
      - elsjaako 4y ago
        I didn't know that!
  - masklinn 4y ago
    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=sid 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.
    - zozbot234 4y ago
      > 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.
      - camgunz 4y ago
        I disagree, but that aside I think the big motivator was embedded support. The reality is what OP said: companies fork GCC.
      - bombolo 4y ago
        > 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.
      - jeroenhd 4y ago
        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-tensilica-xtensa-esp32-backend/65355/5 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.
- skitter 4y ago
  You don't need to write an new frontend for that, just add libgccjit as a backend for rustc.
  - kangalioo 4y ago
    Which has been done, and I'm really sad how that effort has been overshadowed hard by GCCRS, when the latter is much more niche in its use case
- MaxBarraclough 4y ago
  Not so, there some obscure hardware platforms with C compilers but which are unsupported by GCC. GCC has no official backend for PIC or Z80, for instance. Non-standard C-like languages are used in computer graphics and GPU computing (OpenGL, Direct3D, OpenCL), but strictly speaking they don't count as C.
pabs3 4y ago
There is also a project for rustc to use GCC instead of LLVM for codegen. https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc
pabs3 4y ago
What happened to gcj?
- e12e 4y ago
  It grew stale(?) and was dropped in gcc 7.
- bonzini 4y ago
  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.
  - pjmlp 4y ago
    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.
    - bonzini 4y ago
      I meant it compiled bytecode to native ahead of time. There was also a source to native part which was removed first.

hardware2win 4y ago

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

wofo 4y ago
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.
- GrayShade 4y ago
  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 https://github.com/rust-lang/rustc_codegen_gcc
  - masklinn 4y ago
    A rust implementation for people who don’t like rust seems like a strange take.
    - cstrahan 4y ago
      Not too strange. Imagine the reverse: a C compiler written in Rust. There is an awful lot of software in C that I want to use, but I really dislike C itself. If I found some deficiency in C compilers and felt the need to write my own, I certainly would prefer to write it in Rust. It would be a C implementation for people who don't like C.
- hawk_ 4y ago
  No borrow checking is effectively a dialect of Rust?

sp1rit 4y ago

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.

viraptor 4y ago
Is that not what "rustc --emit=obj" does now?
stingraycharles 4y ago
Out of curiosity, why would you need this?
- hgs3 4y ago
  You're basically asking why you'd want object files. They're a container of (usually) relocatable machine code. You can inspect or modify them with nm [1] or objcopy [2]. You can link them with object files generated from other programming languages to mix languages. Maybe you have a custom linker or environment that requires you to convert an ELF or COFF object file to some custom variant. There are lots of reasons. [1] https://linux.die.net/man/1/nm https://linux.die.net/man/1/nm [2] https://linux.die.net/man/1/objcopy https://linux.die.net/man/1/objcopy
deleted 4y ago
[deleted]

skitter 4y ago

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_codegen_gcc https://github.com/rust-lang/rust/tree/master/compiler/rustc...

whyarewheher 4y ago
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
- skitter 4y ago
  rustc got bootstrapped already, so download it. If you want to run the compiler itself on a new architecture, cross-compile. If you still decide to bootstrap it again, that's something that will only need to be done once. And even in that case, you can use the second implementation that already exists, mrustc.
kangalioo 4y ago
I've wondered about this for ages and now know: the people who work on GCCRS wouldn't work on rustc_codegen_gcc for one reason or another (familiarity, culture, personal ideals...?). So GCCRS is not "eating away" at available bandwidth and there's no reason not to let GCCRS developers do their thing, even if rustc_codegen_gcc is a more straightforward way of achieving most goals
IshKebab 4y ago
It's probably not hugely useful from a "I want to compile this Rust code" point of view but I imagine it will at least help iron out ambiguities and bugs in the various specs people are working on. I think there's at least MiniRust and the Ferrocene Language Specification: https://www.youtube.com/watch?v=eFpHadbv34I https://www.youtube.com/watch?v=eFpHadbv34I https://spec.ferrocene.dev/ https://spec.ferrocene.dev/

c0l0 4y ago

Probably a dumb question, but I'd really like to know if this somehow affects/improves Rust's support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?

mlindner 4y ago
I would naively assume that it doesn't affect it at all. Compiling with GCC doesn't magically make dynamic linking better. The limitation in dynamic linking is an element of language design. I'd also note that any Rust you compile with GCC probably shouldn't be dynamically linked with Rust code compiled with rustc.

rurban 4y ago

Their base62 implementation really looks unreviewed. A static 64 byte array for 62 bytes...