3 ms·

And mips64, which rustc recently dumped support for after their attempt to extort funding/resources from Loongson failed: https://github.com/rust-lang/compiler

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.

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.