On Sat, Nov 23, 2024, at 1:09 PM, Jonas Smedegaard wrote: > Quoting Chris Hofstaedtler (2024-11-23 04:16:29) >> * Jonas Smedegaard <jo...@jones.dk> [241122 18:01]: >> > > All release architectures support Rust. We should not accept >> > > release architectures without Rust support. >> > > >> > > A minor set of ports architectures does not have Rust support >> > > yet. >> > >> > Rust is unsupported on i386 and patched to silently assume i686 >> >> i686 is not a problem, as that's the arch baseline for our i386 >> arch since bookworm.
yeah, this is not related to that particular change, but to this: https://wiki.debian.org/ArchitectureSpecificsMemo#i386 in combination with a bad interaction between rustc and LLVM.. >> > - see >> > DEP-3 references in this patch for discussions about that, and the patch >> > itself for a way to more loudly make reverse dependencies aware that >> > code using SSE2 *must* be compiled without optimizations on i386: >> > https://salsa.debian.org/debian/rust-wide/-/blob/debian/latest/debian/patches/2001_fail_non-sse2-x86.patch >> > >> > Beware that Rust team build routines run tests without optimizations, >> > regardless of DEB_BUILD_OPTIONS=noopt, so for libraries maintained by >> > them the issue may go unnoticed until reverse dependencies run into the >> > issue *and* test for it, otherwise it might go unnoticed until users >> > report it. >> >> So maybe it's time to raise the baseline to i686+sse2. > > As I understand the situation with Rust, it is *not* that compiled code > fails to run on old non-SSE2 hardware. Instead, the problem is that the > Rust compiler produces code that is *ALWAYS* broken regardless if target > hardware supports SSE2 or not. > > Yes, your final remark is a "solution" regardless, I just wanted to > emphasize that the problem affects the whole architecture, not only > outdated parts of it. > > ...unless I have misunderstand the situation, obciously. AFAICT, this seems to be true. I was (so far) under the impression so far that this only affects FP arithmetics (i.e., the usual issue one runs into this is test code that does FP operations and then checks that the result is as expected). given that it's not limited to that (see https://github.com/rust-lang/rust/issues/114479#issuecomment-2072052116 and https://github.com/rust-lang/compiler-team/issues/808), the situation is a lot worse! so yeah, I guess we should either A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake) one downside of the i586 approach is that its not a tier 1 target upstream, but a tier 2 without host tools one, similar to armel or mips64el. that means both less testing upstream, and no prebuilt stage0 for (re)bootstrapping, which makes jumping versions more involved. this might affect things like cargo-web/rustc-web on stable, or the ability to quickly catch up with upstream if we lag behind version wise. both A) and B) are rather invasive changes.. if the RT (CCed) has a strong preference I'll of course follow their lead in this matter. otherwise, I'll see how involved the changes for A) are and maybe upload a build of that to experimental in the next week, so that we can do an archive-wide rebuild and see whether things break. p.s.: if you become aware of such an issue with any toolchain, it would be nice to file a bug report *with the corresponding toolchain package in Debian* to make its maintainer (me in this case) aware as well. we could have had 2-3 months head start on tackling this issue if you had done so..
