always broken tier 3 targets #126349
Comments
Noratrieb
added
T-compiler
rustbot
added
the
needs-triage
Noratrieb
removed
the
needs-triage
Probably someone from AVR-Rust @shepmaster @dylanmckay @stappersg |
The M68k backend in LLVM is still being developed and the support in the Rust compiler helps as a guidance. |
Request forwarded to Rahix/avr-hal#560 |
|
Hmm. It's already known that we can only build optimized libcores for AVR. |
jieyouxu
added
the
C-discussion
|
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-gnuSignificantly less disheartening for AVR. |
Agreed. Unoptimized builds do not make any sense for AVR. |
|
@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 |
|
One of the problems with Considering the need for 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). |
|
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? |
|
@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. |
|
@workingjubilee I'm not sure how the fact that 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. |
|
@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 |
|
@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." |
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 People have already actually used the m68k port as bare-metal compiling Rust code which ran on the Sega MegaDrive, for example.
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. |
|
Looking into the ARM64EC failures - how is this code being built? (Also, any time you see MSVC failures, please feel free to summon me - I'm happy to dig into issues, if I know they're happening...) |
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.
Notable:
ran out of registers during register allocation)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.
The text was updated successfully, but these errors were encountered: