This upstream commit should restore rustc defaults to something that actually works on plain old 686:
https://github.com/rust-lang/rust/pull/100969 Martin-Éric On Sat, Feb 20, 2021 at 4:24 PM Martin-Éric Racine <martin-eric.rac...@iki.fi> wrote: > > to 10. jouluk. 2020 klo 23.12 Simon McVittie (s...@debian.org) kirjoitti: > > > > On Thu, 10 Dec 2020 at 21:43:18 +0200, Martin-Éric Racine wrote: > > > I cannot help but wonder what platform defaults GCC uses on i386. > > > > i686 without NOPL, according to > > https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html#i386-is-now-almost-i686 > > (which I believe is still current). > > > > However, rust's interpretation of what "i686" means doesn't seem to be > > the same as gcc's: > > https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353 > > > > > This being said, if anyone asks me, non-PAE 686 ought to be a good > > > enough baseline for i386. Most people who need something faster have > > > moved onto amd64 or some other 64-bit platform. Meanwhile, i386 very > > > much implies old hardware. As such, rising the baseline CPU would > > > needlessly kill the usefulness of the port. > > > > That's assuming that the only purpose of i386 is to have an OS you can > > boot on 32-bit processors, but I suspect it's a lot more common this > > decade to use i386 as a multiarch foreign architecture as a way to run > > legacy 32-bit binaries on an x86_64 CPU, and a higher baseline would be > > beneficial for that. > > > > In particular, the current baseline doesn't assume SSE2, which > > means floating-point calculations on i386 use the i387 instructions > > (-mfpmath=387), which don't always give the same answers as other > > architectures due to extended precision. A baseline with SSE2 would be > > able to use -mfpmath=sse, which "should be considerably faster in the > > majority of cases and avoid the numerical instability problems of 387 > > code" according to gcc documentation. > > > > Ubuntu has dropped i386 as a bootable architecture, but continues to > > compile a subset for multiarch use. I'm sure Debian will eventually do the > > same - I don't know whether it'll be for bullseye or for a future release. > > > > The way to influence these decisions, if you want to, would be to > > volunteer to maintain the i386 port and be one of the people responsible > > for fixing bugs like this. > > Elsewhere an upstream Rust contributor recommended that Debian uses > the i585 target for Rust (and LLVM) on i386, instead of trying to > downgrade the i686 target to produce pentium-pro code. He concedes > that upstream might have made some unfortunate assumptions about what > sort of CPU features are available for the generic i686 target e.g > SSE2, but he feels that Debian using the i586 target would make more > sense if the goal is to produce code that definitely won't > accidentally use unexpected opcodes. > > Martin-Éric
