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. smcv