7 ms·

Why would someone want this? (Honest question)

by outside1234 4y ago

dleslie 4y ago
Gcc has more stable hardware targets than llvm, for starters.
- pavon 4y ago
  Note that there is a separate project to use the GCC backend with the Rustc frontend. At least in the short-term, that project will be the better approach to providing the benefits of more hardware support, since it will be more complete and compatible with the rustc/llvm compiler. The main benefit of a GCC front-end is to move Rust beyond a single vendor, and shakeout ambiguities in the (informal) language specification.
mistrial9 4y ago
alternate architectures; plurality
- nickitolas 4y ago
  Isn't this already addressed by the GCC backend for rustc? (Via libgccjit)
twic 4y ago
Multiple implementations of a standard help shine light into dark corners.
- pca006132 4y ago
  Indeed, but I think they should first create a standard?
  - rob74 4y ago
    If not a standard, then at least a specification. This discussion is from 2020, so I'm not sure if it's still up to date: https://users.rust-lang.org/t/where-is-the-rust-language-specification/42047 https://users.rust-lang.org/t/where-is-the-rust-language-spe... "For the most part though, rustc itself is the spec" - so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? And try to keep up with all the changes which will inevitably happen in the LLVM frontend while you are implementing the GCC frontend?
    - b3morales 4y ago
      Integration-style tests are a good tool here. Given a set of programs in the target language with certain expected behavior on the reference compiler, you check that compiling and running with the second compiler produces the same behavior.
    - steveklabnik 4y ago
      > so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? At a high level, this is correct: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Questions#what-is-the-plan-for-inconsistencies-in-behaviour https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques... > If gccrs interprets a program differently from rustc, this is considered a bug. I don't believe they are only reading the frontend, but using the reference first, then looking to the implementation second, and asking a lot of questions along the way.
  - Alghranokk 4y ago
    Rust already has stable standards. There's Rust editions 2015 (1.0), 2018 (1.31.0), and 2021 (1.56.0).
    - wging 4y ago
      Unfortunately that's not quite the same thing as a standard in the sense that is meant here. A 'standard' is a written document that explains how the language should work. A standard that just says "the compiler is correct if it compiles code the way that rustc 1.xy does" is technically unambiguous in that it provides a procedure by which a compiler author can check their work, but leaves quite a bit on the table and is probably the wrong goal to aim at in the long term, even if it enables forward progress for now. (For example, we know rustc contains bugs; do we want gcc-rust to include all the bugs, or should it differ from rustc in that respect? Which behaviors are bugs, which are undesired but accepted quirks of the language, and which are intentional? For that matter, it's unreasonable to expect gcc-rust to produce binaries that are byte-for-byte identical, so what other mechanism should be used to determine equivalence?) (btw, there's also https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/)
      - thesuperbigfrog 4y ago
        Correct. With an ideal standard document that describes the language, someone could build a compiler for the language from scratch and it should behave correctly. See https://en.wikipedia.org/wiki/Programming_language_specification https://en.wikipedia.org/wiki/Programming_language_specifica... Some example standards: C: https://www.open-std.org/jtc1/sc22/wg14/ https://www.open-std.org/jtc1/sc22/wg14/ ECMAScript (Javascript): https://tc39.es/ecma262/ https://tc39.es/ecma262/ C++: https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard Scheme: https://schemers.org/Documents/Standards/ https://schemers.org/Documents/Standards/ Ada: http://www.ada-auth.org/standards/ada12_w_tc1.html http://www.ada-auth.org/standards/ada12_w_tc1.html For Rust, Ferrous Systems is working on the Ferrocene Language Specification to formally document the Rust subset that Ferrocene will use. https://ferrous-systems.com/blog/ferrocene-language-specification/ https://ferrous-systems.com/blog/ferrocene-language-specific... https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/
  - pornel 4y ago
    There are various reference documents for Rust, but how do you know if they're complete and accurate without creating a working interoperable implementation? ISO will stamp any fantasy like OOXML, but that doesn't mean the standard is useful.
  - int_19h 4y ago
    Having another implementation first actually helps create a good standard, by highlighting things that are implementation-specific assumptions.
lmkg 4y ago
The main source of interest for GCC Rust is because GCC targets more platforms than LLVM. A partially-overlapping interest is using Rust in Linux: Linux targets non-LLVM platforms, but is also deeply tied to GCC and Rust-for-Linux would have a lower barrier to entry if it doesn't require a second toolchain. Long-term, it's considered a strong signal for the health and viability of Rust if it's not strictly tied to one implementation.
- potatochup 4y ago
  Yup. We have microcontrollers that we'd like to write rust on, but we can't because llvm doesn't support the architecture.
  - 3836293648 4y ago
    But that's not an argument for GCC-RS, that's an argument for rustc_codegen_gcc. The purpose of GCC-RS is a) licensing and b) fracturing the community to stabilise the language spec, something I'm very doubtful over for at least a few more years.
  - tcmart14 4y ago
    A question for curiosity since I don't know much about llvm and specifically the architecture. Does LLVM not support architectures because there is some barrier, or a higher barrier than GCC? And GCC makes it easier to support some architectures or is it just as easy to add the support to LLVM but no one does it because GCC already supports it?
    - cozzyd 4y ago
      The vendor sometimes does this and GCC is much more standard in the embedded space. And crucially, it's required to be open source. For example, for arm-none-eabi, ARM provides a GCC toolchain (https://developer.arm.com/Tools%20and%20Software/GNU%20Toolchain https://developer.arm.com/Tools%20and%20Software/GNU%20Toolc...) but makes you purchase the LLVM-based one (https://developer.arm.com/Tools%20and%20Software/Arm%20Compiler%20for%20Embedded https://developer.arm.com/Tools%20and%20Software/Arm%20Compi...). Now I'm fairly certain there's an open-source way to target ARM microcontrollers with LLVM but you can't download it from ARM...
bitwize 4y ago
GCC already has compiler front ends for Fortran, Ada, Go, and formerly Java. Adding another language, especially one as popular as Rust, couldn't hurt.
- brundolf 4y ago
  Huh, I didn't realize that
  - syvon 4y ago
    A common misconception is that GCC stands for GNU C Compiler, but it stands for GNU Compiler Collection. Perhaps why you did not realize ;)
    - kstrauser 4y ago
      GNU C Compiler was the original name. A lot of us probably never bothered updating our mental acronym tables.
      - bzxcvbn 4y ago
        You mean to tell me that the acronym settled in your head between March and December 1987 and you never reconsidered since then?
        kstrauser 4y ago
        Nope. It settled in my head before it was renamed in 1999: https://gcc.gnu.org/wiki/History#Reunification https://gcc.gnu.org/wiki/History#Reunification
    - brundolf 4y ago
      I didn't know that either! And I've even used it before, haha
    - wtetzner 4y ago
      But I assume the name of the gcc binary stands for GNU C Compiler?
pabs3 4y ago
It is also useful for building rustc from source without any rustc binaries, although mrustc (a Rust to C transpiler) was supposed to be good for that too.
pornel 4y ago
Another angle is that GNU wants this, because they want GCC to stay relevant and competitive. Rising popularity of LLVM-only Rust gives advantage to their competitor.
- pjmlp 4y ago
  No worries, it will keep releavant, now that Apple and Google apparently took out their support from clang, and most other vendors that benefit from MIT aren't that keen into pushing C++ changes upstream, clang is getting a nice third place in C++20 support.
  - cozzyd 4y ago
    Apple Clang is already a completely different beast than upstream, right? At least the version numbers are nonsensical unnecessarily complicating feature support checks in my experience as someone who doesn't own any Macs but writes software that others insist on trying to compile on a Mac...
    - pjmlp 4y ago
      Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS. In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit. For everything else there is Objective-C and Swift. Then Google apparently drop off clang after the ABI break votes didn't went the way they wanted, so they are now focusing on Abseil, and their style guide is anyway quite restrictive. So now we are in this ironic situation, that VC++ from all compilers is the one with best C++20 support, closely followed by GCC, and then there is clang and the other lesser known ones still lagging in C++17 and earlier.
      - lenkite 4y ago
        Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress! It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.
chomp 4y ago
A significant chunk of this drive is for the Rust/Linux kernel project.
ruuda 4y ago
Another reason besides platform support, is bootstrapping and verifiable builds. rustc can only be built by a recent rustc, so it is a pain to bootstrap from source if you don't want to trust a big binary.
- steveklabnik 4y ago
  https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).
  - ruuda 4y ago
    Ah, I didn't realize it could do 1.54 now, neat! Last time I looked at the state of bootstrapping rustc in Nix and Guix, mrustc could only do 1.20-something, and you had to build a dozen rustcs to get to the current version. Does mrustc keep up now though? With 1.63 in beta it's still quite a chain to build from 1.54.
tcmart14 4y ago
I didn't see this mentioned in any replies, but I think another reason why this is wanted is for Rust in the linux kernel development. If Rust can compile using GCC tooling, it should be easier to integrate into the build process for the Linux kernel. As it stands now, if Linux kernel development allowed Rust in areas of the kernel outside of modules and drivers, you need the GCC tool chain to build the kernel and the llvm toolchain. So it also meets a requirement, or at least greases the wheels, for the possibility of getting Rust into the Linux kernel.
- wongarsu 4y ago
  And while you can link a gcc-compiled kernel with llvm-compiled rust, apparently you lose some link-time optimization, and with that control-flow integrity [1]. That's a potential security concern for the kernel, in addition to the usability issues of using two toolchains. 1: https://www.cs.ucy.ac.cy/~elathan/papers/tops20.pdf https://www.cs.ucy.ac.cy/~elathan/papers/tops20.pdf
  - JoshTriplett 4y ago
    rustc_codegen_gcc will solve the same problem. I would expect it to be possible to do LTO and CFI across rustc_codegen_gcc and gcc-compiled C or C++ code.
hedora 4y ago
Competition. GCC had laughably bad error messages before LLVM caught on. Even then, LLVM generated terrible code compared to GCC. There's a similar competition going on with open source linkers (which are finally going multi-threaded). Both compiler toolchains currently blow pre-LLVM GCC out of the water (and GCC development has noticeably accelerated since LLVM came out). I'm not sure which one is better at which C++ thing these days, but I'll bet GCC Rust will beat LLVM Rust at some important things in a few years (and then vice versa).
- nequo 4y ago
  Similar story to Vim/Nvim and maybe partly OpenSSL/LibreSSL. Forking (not all technically forking) is good sometimes.
- pjmlp 4y ago
  And now clang is lagging in C++20 support, and modules will come in 2 to 3 years as per roadmap (right after C++23 is done), while VC++ already has them, and GCC head is catching on relatively fast.

Why would someone want this? (Honest question)

dleslie 4y ago

Gcc has more stable hardware targets than llvm, for starters.

pavon 4y ago
Note that there is a separate project to use the GCC backend with the Rustc frontend. At least in the short-term, that project will be the better approach to providing the benefits of more hardware support, since it will be more complete and compatible with the rustc/llvm compiler. The main benefit of a GCC front-end is to move Rust beyond a single vendor, and shakeout ambiguities in the (informal) language specification.

mistrial9 4y ago

alternate architectures; plurality

nickitolas 4y ago
Isn't this already addressed by the GCC backend for rustc? (Via libgccjit)

twic 4y ago

Multiple implementations of a standard help shine light into dark corners.

pca006132 4y ago
Indeed, but I think they should first create a standard?
- rob74 4y ago
  If not a standard, then at least a specification. This discussion is from 2020, so I'm not sure if it's still up to date: https://users.rust-lang.org/t/where-is-the-rust-language-specification/42047 https://users.rust-lang.org/t/where-is-the-rust-language-spe... "For the most part though, rustc itself is the spec" - so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? And try to keep up with all the changes which will inevitably happen in the LLVM frontend while you are implementing the GCC frontend?
  - b3morales 4y ago
    Integration-style tests are a good tool here. Given a set of programs in the target language with certain expected behavior on the reference compiler, you check that compiling and running with the second compiler produces the same behavior.
  - steveklabnik 4y ago
    > so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? At a high level, this is correct: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Questions#what-is-the-plan-for-inconsistencies-in-behaviour https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques... > If gccrs interprets a program differently from rustc, this is considered a bug. I don't believe they are only reading the frontend, but using the reference first, then looking to the implementation second, and asking a lot of questions along the way.
- Alghranokk 4y ago
  Rust already has stable standards. There's Rust editions 2015 (1.0), 2018 (1.31.0), and 2021 (1.56.0).
  - wging 4y ago
    Unfortunately that's not quite the same thing as a standard in the sense that is meant here. A 'standard' is a written document that explains how the language should work. A standard that just says "the compiler is correct if it compiles code the way that rustc 1.xy does" is technically unambiguous in that it provides a procedure by which a compiler author can check their work, but leaves quite a bit on the table and is probably the wrong goal to aim at in the long term, even if it enables forward progress for now. (For example, we know rustc contains bugs; do we want gcc-rust to include all the bugs, or should it differ from rustc in that respect? Which behaviors are bugs, which are undesired but accepted quirks of the language, and which are intentional? For that matter, it's unreasonable to expect gcc-rust to produce binaries that are byte-for-byte identical, so what other mechanism should be used to determine equivalence?) (btw, there's also https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/)
    - thesuperbigfrog 4y ago
      Correct. With an ideal standard document that describes the language, someone could build a compiler for the language from scratch and it should behave correctly. See https://en.wikipedia.org/wiki/Programming_language_specification https://en.wikipedia.org/wiki/Programming_language_specifica... Some example standards: C: https://www.open-std.org/jtc1/sc22/wg14/ https://www.open-std.org/jtc1/sc22/wg14/ ECMAScript (Javascript): https://tc39.es/ecma262/ https://tc39.es/ecma262/ C++: https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard Scheme: https://schemers.org/Documents/Standards/ https://schemers.org/Documents/Standards/ Ada: http://www.ada-auth.org/standards/ada12_w_tc1.html http://www.ada-auth.org/standards/ada12_w_tc1.html For Rust, Ferrous Systems is working on the Ferrocene Language Specification to formally document the Rust subset that Ferrocene will use. https://ferrous-systems.com/blog/ferrocene-language-specification/ https://ferrous-systems.com/blog/ferrocene-language-specific... https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/
- pornel 4y ago
  There are various reference documents for Rust, but how do you know if they're complete and accurate without creating a working interoperable implementation? ISO will stamp any fantasy like OOXML, but that doesn't mean the standard is useful.
- int_19h 4y ago
  Having another implementation first actually helps create a good standard, by highlighting things that are implementation-specific assumptions.

lmkg 4y ago

The main source of interest for GCC Rust is because GCC targets more platforms than LLVM. A partially-overlapping interest is using Rust in Linux: Linux targets non-LLVM platforms, but is also deeply tied to GCC and Rust-for-Linux would have a lower barrier to entry if it doesn't require a second toolchain. Long-term, it's considered a strong signal for the health and viability of Rust if it's not strictly tied to one implementation.

potatochup 4y ago
Yup. We have microcontrollers that we'd like to write rust on, but we can't because llvm doesn't support the architecture.
- 3836293648 4y ago
  But that's not an argument for GCC-RS, that's an argument for rustc_codegen_gcc. The purpose of GCC-RS is a) licensing and b) fracturing the community to stabilise the language spec, something I'm very doubtful over for at least a few more years.
- tcmart14 4y ago
  A question for curiosity since I don't know much about llvm and specifically the architecture. Does LLVM not support architectures because there is some barrier, or a higher barrier than GCC? And GCC makes it easier to support some architectures or is it just as easy to add the support to LLVM but no one does it because GCC already supports it?
  - cozzyd 4y ago
    The vendor sometimes does this and GCC is much more standard in the embedded space. And crucially, it's required to be open source. For example, for arm-none-eabi, ARM provides a GCC toolchain (https://developer.arm.com/Tools%20and%20Software/GNU%20Toolchain https://developer.arm.com/Tools%20and%20Software/GNU%20Toolc...) but makes you purchase the LLVM-based one (https://developer.arm.com/Tools%20and%20Software/Arm%20Compiler%20for%20Embedded https://developer.arm.com/Tools%20and%20Software/Arm%20Compi...). Now I'm fairly certain there's an open-source way to target ARM microcontrollers with LLVM but you can't download it from ARM...

bitwize 4y ago

GCC already has compiler front ends for Fortran, Ada, Go, and formerly Java. Adding another language, especially one as popular as Rust, couldn't hurt.

brundolf 4y ago
Huh, I didn't realize that
- syvon 4y ago
  A common misconception is that GCC stands for GNU C Compiler, but it stands for GNU Compiler Collection. Perhaps why you did not realize ;)
  - kstrauser 4y ago
    GNU C Compiler was the original name. A lot of us probably never bothered updating our mental acronym tables.
    - bzxcvbn 4y ago
      You mean to tell me that the acronym settled in your head between March and December 1987 and you never reconsidered since then?
      - kstrauser 4y ago
        Nope. It settled in my head before it was renamed in 1999: https://gcc.gnu.org/wiki/History#Reunification https://gcc.gnu.org/wiki/History#Reunification
  - brundolf 4y ago
    I didn't know that either! And I've even used it before, haha
  - wtetzner 4y ago
    But I assume the name of the gcc binary stands for GNU C Compiler?

pabs3 4y ago

It is also useful for building rustc from source without any rustc binaries, although mrustc (a Rust to C transpiler) was supposed to be good for that too.

pornel 4y ago

Another angle is that GNU wants this, because they want GCC to stay relevant and competitive. Rising popularity of LLVM-only Rust gives advantage to their competitor.

pjmlp 4y ago
No worries, it will keep releavant, now that Apple and Google apparently took out their support from clang, and most other vendors that benefit from MIT aren't that keen into pushing C++ changes upstream, clang is getting a nice third place in C++20 support.
- cozzyd 4y ago
  Apple Clang is already a completely different beast than upstream, right? At least the version numbers are nonsensical unnecessarily complicating feature support checks in my experience as someone who doesn't own any Macs but writes software that others insist on trying to compile on a Mac...
  - pjmlp 4y ago
    Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS. In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit. For everything else there is Objective-C and Swift. Then Google apparently drop off clang after the ABI break votes didn't went the way they wanted, so they are now focusing on Abseil, and their style guide is anyway quite restrictive. So now we are in this ironic situation, that VC++ from all compilers is the one with best C++20 support, closely followed by GCC, and then there is clang and the other lesser known ones still lagging in C++17 and earlier.
    - lenkite 4y ago
      Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress! It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.

chomp 4y ago

A significant chunk of this drive is for the Rust/Linux kernel project.

ruuda 4y ago

Another reason besides platform support, is bootstrapping and verifiable builds. rustc can only be built by a recent rustc, so it is a pain to bootstrap from source if you don't want to trust a big binary.

steveklabnik 4y ago
https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).
- ruuda 4y ago
  Ah, I didn't realize it could do 1.54 now, neat! Last time I looked at the state of bootstrapping rustc in Nix and Guix, mrustc could only do 1.20-something, and you had to build a dozen rustcs to get to the current version. Does mrustc keep up now though? With 1.63 in beta it's still quite a chain to build from 1.54.

tcmart14 4y ago

I didn't see this mentioned in any replies, but I think another reason why this is wanted is for Rust in the linux kernel development. If Rust can compile using GCC tooling, it should be easier to integrate into the build process for the Linux kernel. As it stands now, if Linux kernel development allowed Rust in areas of the kernel outside of modules and drivers, you need the GCC tool chain to build the kernel and the llvm toolchain. So it also meets a requirement, or at least greases the wheels, for the possibility of getting Rust into the Linux kernel.

wongarsu 4y ago
And while you can link a gcc-compiled kernel with llvm-compiled rust, apparently you lose some link-time optimization, and with that control-flow integrity [1]. That's a potential security concern for the kernel, in addition to the usability issues of using two toolchains. 1: https://www.cs.ucy.ac.cy/~elathan/papers/tops20.pdf https://www.cs.ucy.ac.cy/~elathan/papers/tops20.pdf
- JoshTriplett 4y ago
  rustc_codegen_gcc will solve the same problem. I would expect it to be possible to do LTO and CFI across rustc_codegen_gcc and gcc-compiled C or C++ code.

hedora 4y ago

Competition. GCC had laughably bad error messages before LLVM caught on. Even then, LLVM generated terrible code compared to GCC. There's a similar competition going on with open source linkers (which are finally going multi-threaded). Both compiler toolchains currently blow pre-LLVM GCC out of the water (and GCC development has noticeably accelerated since LLVM came out). I'm not sure which one is better at which C++ thing these days, but I'll bet GCC Rust will beat LLVM Rust at some important things in a few years (and then vice versa).

nequo 4y ago
Similar story to Vim/Nvim and maybe partly OpenSSL/LibreSSL. Forking (not all technically forking) is good sometimes.
pjmlp 4y ago
And now clang is lagging in C++20 support, and modules will come in 2 to 3 years as per roadmap (right after C++23 is done), while VC++ already has them, and GCC head is catching on relatively fast.