On Thu, Feb 13, 2025 at 12:35:51PM +0100, Matthias Klose wrote: > I don't think such changes should be made a few weeks before a freeze, or if > that change should be made at all. This is a discussion that should be made > during the freeze and then implemented at the start of the next release > cycle.
Obviously, if this issue had been known (on our/Debian end) earlier then end of Nov '24 it would have been raised earlier. Alas, none of us have a time machine.. > The current baseline is i686-linux-gnu, without access to any SSE > instructions. Apparently other toolchains are actively raising these > baselines, or are unaware about what is used as a baseline upstream (as seen > in here for LLVM and rustc). That LLVM and rustc upstream have a different baseline has been known for basically ever. Until the referenced discussions in November, at least I was under the impression that the only downside of this difference is the different FP behaviour (and resulting patches, mostly to test suites, assuming the upstream default semantics/precision). Neither rustc nor LLVM packages in Debian violate the current i386 baseline. They are just (quite subtly!) broken under it, and the only fix according to both upstream projects is to raise the baseline. Note that rustc at least will forbid what we are currently doing soon for exactly this reason (which we can of course patch out again, but at that point I'd honestly rather drop i386 altogether). > Mixing fp87 and SSE instructions leads to a performance penalty (I don't > have references to that, so people might want to investigate). > > fp87 instructions also show some excess precision, so test cases and test > suites of packages might be affected by this change as well. I am fully prepared to handle that on the Rust side, and can help with the LLVM side as well - this will mostly be dropping Debian-specific patches and verifying the results, as upstreams projects using rustc or LLVM will assume the usptream baseline, not the (from their PoV, strange) Debian one. > When preparing for such a change (maybe during the freeze when the archive > is not active), please do at least a comparative test rebuild with these > changes, also checking that affected toolchains adhere to the new baseline. > A test rebuild still does not cover the use of the rebuilt binaries as > dependencies. The number of Rust cdylibs in the archive is tiny, everything else is covered by a rebuild. > Is this really worth doing that change, alternatives could also include to > retire the i386 port, or to keep the status quo, and document that packages > built by toolchains with unknown baselines might not run on some hardware. The issue is unfortunately not that they might not run on some hardware (that would be the case if we were to selectively violate the baseline by bumping it in rustc/LLVM while still pretending Debian's i386 baseline doesn't require SSE2/MMX, which nobody is suggesting!), but that they are miscompiled and then segfault (depending on execution path, so hard to catch until people run into it) both on hardware that supports and hardware that doesn't support SSE2.
