3 ms·

So we'll finally see Rust support for all the architectures that gcc supports that LLVM doesn't, like Alpha, SuperH and VAX, for starters. That'll be nice!

segfaultbuserr 3y ago
Can't wait to see some PDP-11 machine code from Rust (the last time I checked, freestanding C compiling still worked on GCC).
Asraelite 3y ago
I would assume it also means additional configuration options for already-supported architectures. For example, I recently discovered that with RISC-V, GCC supports the RV32E target but LLVM doesn't.
- monocasa 3y ago
  Are you sure about that? I was pretty sure that llvm has supported RV32E for years now. https://reviews.llvm.org/D70401?id=395048 https://reviews.llvm.org/D70401?id=395048
  - Asraelite 3y ago
    Oh, last time I checked clang didn't support it. In any case, there are a lot of other compiler flags that are exclusive to gcc.
crotchfire 3y ago
And mips64, which rustc recently dumped support for after their attempt to extort funding/resources from Loongson failed: https://github.com/rust-lang/compiler-team/issues/648 https://github.com/rust-lang/compiler-team/issues/648 This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies. GNU may have annoyingly-higher standards for merging changes, but once it's in there and supported they will keep it for the long haul. It's like buying vs renting. It takes a lot more dev hours to get support into GCC, but once it's there, it stays there.
- khuey 3y ago
  > This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies. I have a hard time seeing this as a bad thing. Hardware companies seem like the most logical people to pay for maintaining support for the architectures they sell.
  - crotchfire 3y ago
    The pain is inflicted not on the hardware companies or future customers, but on their past customers. Their customers pay full cost up front. Vendors can pay full dev cost up front too. GCC's model encourages this.
- estebank 3y ago
  Support wasn't dumped, it was demoted from Tier 2 to Tier 3 to better reflect the level of support that backend effectively already had. As mentioned in that thread, if someone steps up to maintain it, it can be bumped again to Tier 2. Be aware that GCC doesn't have a similar level of specificity about the state of each platform they support. There are packages in Debian that "compile" but when trying to execute them on "exotic" platforms you encounter bugs immediately. Supporting a platform in a static codebase of a compiler is easy, but in codebases actively being worked on, like GCC and LLVM, keeping things working is not trivial.

segfaultbuserr 3y ago

Can't wait to see some PDP-11 machine code from Rust (the last time I checked, freestanding C compiling still worked on GCC).

Asraelite 3y ago

I would assume it also means additional configuration options for already-supported architectures. For example, I recently discovered that with RISC-V, GCC supports the RV32E target but LLVM doesn't.

monocasa 3y ago
Are you sure about that? I was pretty sure that llvm has supported RV32E for years now. https://reviews.llvm.org/D70401?id=395048 https://reviews.llvm.org/D70401?id=395048
- Asraelite 3y ago
  Oh, last time I checked clang didn't support it. In any case, there are a lot of other compiler flags that are exclusive to gcc.

crotchfire 3y ago

And mips64, which rustc recently dumped support for after their attempt to extort funding/resources from Loongson failed: https://github.com/rust-lang/compiler-team/issues/648 https://github.com/rust-lang/compiler-team/issues/648 This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies. GNU may have annoyingly-higher standards for merging changes, but once it's in there and supported they will keep it for the long haul. It's like buying vs renting. It takes a lot more dev hours to get support into GCC, but once it's there, it stays there.

khuey 3y ago
> This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies. I have a hard time seeing this as a bad thing. Hardware companies seem like the most logical people to pay for maintaining support for the architectures they sell.
- crotchfire 3y ago
  The pain is inflicted not on the hardware companies or future customers, but on their past customers. Their customers pay full cost up front. Vendors can pay full dev cost up front too. GCC's model encourages this.
estebank 3y ago
Support wasn't dumped, it was demoted from Tier 2 to Tier 3 to better reflect the level of support that backend effectively already had. As mentioned in that thread, if someone steps up to maintain it, it can be bumped again to Tier 2. Be aware that GCC doesn't have a similar level of specificity about the state of each platform they support. There are packages in Debian that "compile" but when trying to execute them on "exotic" platforms you encounter bugs immediately. Supporting a platform in a static codebase of a compiler is easy, but in codebases actively being worked on, like GCC and LLVM, keeping things working is not trivial.