always broken tier 3 targets

[Nilstrieb]

We have some tier 3 targets that don't even build core. I wrote https://github.com/Nilstrieb/does-it-build/tree/cd5b26e3cee3ceab7aef734800d89159d06731d5 to track that over time, and found the following results.

This table is the list of targets (that exist today) that fail to build core on nightlies this year. This of course includes new targets that don't build on older compilers, but also includes some always broken targets.

results/2024-01-01 aarch64-apple-visionos,aarch64-apple-visionos-sim,arm64ec-pc-windows-msvc,armv8r-none-eabihf,avr-unknown-gnu-atmega328,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,powerpc64-unknown-linux-musl,riscv32im-risc0-zkvm-elf,riscv32ima-unknown-none-elf,riscv32imafc-esp-espidf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
results/2024-01-15 aarch64-apple-visionos,aarch64-apple-visionos-sim,arm64ec-pc-windows-msvc,armv8r-none-eabihf,avr-unknown-gnu-atmega328,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,powerpc64-unknown-linux-musl,riscv32im-risc0-zkvm-elf,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
results/2024-02-01 aarch64-apple-visionos,aarch64-apple-visionos-sim,arm64ec-pc-windows-msvc,armv8r-none-eabihf,avr-unknown-gnu-atmega328,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
results/2024-02-15 aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64_be-unknown-linux-gnu,aarch64_be-unknown-linux-gnu_ilp32,aarch64_be-unknown-netbsd,arm64ec-pc-windows-msvc,avr-unknown-gnu-atmega328,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
results/2024-03-01 aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64_be-unknown-linux-gnu,aarch64_be-unknown-linux-gnu_ilp32,aarch64_be-unknown-netbsd,arm64ec-pc-windows-msvc,avr-unknown-gnu-atmega328,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,x86_64-unknown-linux-none
results/2024-03-15 aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64_be-unknown-linux-gnu,aarch64_be-unknown-linux-gnu_ilp32,aarch64_be-unknown-netbsd,avr-unknown-gnu-atmega328,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,x86_64-unknown-linux-none
results/2024-04-01 aarch64-apple-visionos,aarch64-apple-visionos-sim,avr-unknown-gnu-atmega328,m68k-unknown-linux-gnu,x86_64-unknown-linux-none
results/2024-04-15 avr-unknown-gnu-atmega328,m68k-unknown-linux-gnu,x86_64-unknown-linux-none
results/2024-05-01 avr-unknown-gnu-atmega328,m68k-unknown-linux-gnu,x86_64-unknown-linux-none
results/2024-05-15 avr-unknown-gnu-atmega328,hexagon-unknown-none-elf,m68k-unknown-linux-gnu
results/2024-06-01 avr-unknown-gnu-atmega328,m68k-unknown-linux-gnu

Notable:

• avr-unknown-gnu-atmega328 (ran out of registers during register allocation)
• m68k-unknown-linux-gnu (rustc-LLVM ERROR: Cannot select: 0x7f538f9ad930: ch = AtomicStore<(store unordered (s16) into %ir.23)> 0x7f538f9be540, 0x7f538f8af380, 0x7f538f9ad4d0)

these two targets are always broken, failing in LLVM. they should probably be deleted.

It would probably make sense to require successfully building core for a target to be considered tier 3. Core doesn't have the maintenance burden std has, and if something can't build core, it's pretty much useless.

[Nilstrieb]

@glaubitz @ricky26 for m68k no one for avr!

[RossSmyth]

no one for avr!

Probably someone from AVR-Rust @shepmaster @dylanmckay @stappersg

[glaubitz]

these two targets are always broken, failing in LLVM. they should probably be deleted.

It would probably make sense to require successfully building core for a target to be considered tier 3. Core doesn't have the maintenance burden std has, and if something can't build core, it's pretty much useless.

The M68k backend in LLVM is still being developed and the support in the Rust compiler helps as a guidance.

[stappersg]

no one for avr!

Probably someone from AVR-Rust @shepmaster @dylanmckay @stappersg

Request forwarded to https://github.com/Rahix/avr-hal/issues/560

[workingjubilee]

Hmm. It's already known that we can only build optimized libcores for AVR.

[workingjubilee]

With https://github.com/Nilstrieb/does-it-build/pull/1 we would get the following results:

$ ls . | xargs head -1
==> 2024-01-01 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,arm64ec-pc-windows-msvc,armv8r-none-eabihf,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,powerpc64-unknown-linux-musl,riscv32im-risc0-zkvm-elf,riscv32ima-unknown-none-elf,riscv32imafc-esp-espidf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
==> 2024-01-15 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,arm64ec-pc-windows-msvc,armv8r-none-eabihf,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,powerpc64-unknown-linux-musl,riscv32im-risc0-zkvm-elf,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
==> 2024-02-01 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,arm64ec-pc-windows-msvc,armv8r-none-eabihf,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
==> 2024-02-15 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64_be-unknown-linux-gnu,aarch64_be-unknown-linux-gnu_ilp32,aarch64_be-unknown-netbsd,arm64ec-pc-windows-msvc,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,wasm32-wasip2,x86_64-unknown-linux-none
==> 2024-03-01 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64_be-unknown-linux-gnu,aarch64_be-unknown-linux-gnu_ilp32,aarch64_be-unknown-netbsd,arm64ec-pc-windows-msvc,loongarch64-unknown-linux-musl,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,wasm32-wasip1,wasm32-wasip1-threads,x86_64-unknown-linux-none
==> 2024-03-15 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64_be-unknown-linux-gnu,aarch64_be-unknown-linux-gnu_ilp32,aarch64_be-unknown-netbsd,m68k-unknown-linux-gnu,riscv32ima-unknown-none-elf,x86_64-unknown-linux-none
==> 2024-04-01 <==
aarch64-apple-visionos,aarch64-apple-visionos-sim,m68k-unknown-linux-gnu,x86_64-unknown-linux-none
==> 2024-04-15 <==
hexagon-unknown-none-elf,m68k-unknown-linux-gnu,x86_64-unknown-linux-none
==> 2024-05-01 <==
avr-unknown-gnu-atmega328,m68k-unknown-linux-gnu,x86_64-unknown-linux-none
==> 2024-05-15 <==
hexagon-unknown-none-elf,m68k-unknown-linux-gnu
==> 2024-06-01 <==
m68k-unknown-linux-gnu

Significantly less disheartening for AVR.

[Rahix]

Hmm. It's already known that we can only build optimized libcores for AVR.

Agreed. Unoptimized builds do not make any sense for AVR.

[workingjubilee]

@Rahix If that is really true then please PR disabling lower optimization levels for AVR targets (or promoting lower levels to higher levels, or reinterpreting them, or defaulting it higher, or perma-locking it to -Copt-level=s, whatever).

[workingjubilee]

One of the problems with -Zbuild-std is that it requires incredibly arcane supplemental invocations to make it work in common use-cases. It's not acceptable for it to randomly be broken for a target like that because everyone needs to add additional configuration. That should just be embedded in the directives for building the necessary components. Directly.

Considering the need for -Zbuild-std in the embedded community the current situation where everyone says "that would be nice someday!" and people are extremely reluctant to pitch in to fix even minor UX issues is inappropriate.

In general, the real reason we should remove these targets (if we do) is the one that people consider impolite to actually name: community disinterest in actually contributing. We still do not have any listed official maintainers for AVR, as no one has dared to attach their name to its platform support page, despite some being willing to send in PRs in general (which is appreciated! but not quite the same).

[glaubitz]

I'm not sure I understand the point of this discussion. If these targets were working properly, they wouldn't be considered Tier 3, would they?

[workingjubilee]

@glaubitz The point of this discussion is that advertising the target at all is a suggestion that it ought to work. And people can get very stubborn if the targets don't work how they imagine it should work, antagonizing those who would attempt to repair the compiler's functionality in general because the compiler is imperfect for their use-case. This can get pretty stressful when there is no one who has agreed to officially share the burden.

Even when tier 3 targets do have designated maintainers, those maintainers occasionally expect more investment than we normally give tier 3 targets. Things like notifications if their target stopped building, for instance.

The community, in other words, disagrees with our strategy of allowing tier 3 to remain unconditionally at tier 3, basically without regard to how well it works or not. This is somewhat vexing for everyone, as there are perfectly legitimate reasons... the ones originally conceived for tier 3 targets, like "we recently added this and it's not even finished yet" or "this is fairly experimental"... to have tier 3 targets. But it becomes perceived as "tier 2 lite" when a fairly functional target persists forever at tier 3 without ever trying to move up, and that creates social pressure to extend additional maintenance effort, beyond what the Rust teams initially agreed to, for these targets.

[glaubitz]

@workingjubilee I'm not sure how the fact that rustc --print-targets list a certain target puts pressure on anyone to ensure that a target listed there needs to work. This sounds like a constructed scenario to me.

NetBSD has a similar tier system and I have never heard anyone bring up the conversation about alleged pressure to fix targets. In fact, many targets such as VAX were broken for a long time before they were brought back to live.

It's just how community-maintained projects work and it's perfectly fine in my opinion.

[Nilstrieb]

@glaubitz no, tier 3 targets are supposed to work, all targets are supposed to work, there's no reason to have a target that doesn't work. tier 3 just means that it may break intermittently in a PR, and then it should be fixed again

[workingjubilee]

@glaubitz Do you... like... want me to link you the examples I was thinking of? I was trying to avoid putting anyone in specific on blast.

In any case, I do not think that the troubles that beset NetBSD are that likely to be exactly the same as those that haunt the Rust issue tracker. As Tolstoy said, "All happy families are alike; each unhappy family is unhappy in its own way."

[glaubitz]

@glaubitz no, tier 3 targets are supposed to work, all targets are supposed to work, there's no reason to have a target that doesn't work. tier 3 just means that it may break intermittently in a PR, and then it should be fixed again

The M68k backend in LLVM is still experimental, but improving continuously. Currently, we're in the progress on fixing FPU support which will most certainly resolve one of the biggest blockers for building rustc for this target.

People have already actually used the m68k port as bare-metal compiling Rust code which ran on the Sega MegaDrive, for example.

@glaubitz Do you... like... want me to link you the examples I was thinking of? I was trying to avoid putting anyone in specific on blast.

I was simply wondering who in particular was complaining about the m68k port. I would expect everyone interested in the m68k port to be aware of the fact that it's still work in progress and the best way to get it into a usable state is join our efforts.