always broken tier 3 targets

[Noratrieb]

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.

[Noratrieb]

@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 Rahix/avr-hal#560

[workingjubilee]

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

[workingjubilee]

With Noratrieb/does-it-build#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).