Repository navigation
Our x86-32 target names are inconsistent #136495
Description
The typical naming scheme we use for x86-32 targets is:
- i686 means Pentium 4 (yes that makes no sense but, well, it's too disruptive to change now and i786 didn't catch on as a name anywhere), which in particular have SSE2
- i586 means "original Pentium" (no SSE)
We have some targets that violate this:
- i686-linux-android is actually PentiumPro with SSE, but that seems sufficiently close to Pentium 4 that it's still the right name IMO (in particular, it does have more vector extensions than Pentium 4; not sure why we are using "Pentium Pro" as the baseline) (resolved by i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change #136885)
- i386-apple-ios uses Penryn as baseline, way newer than Pentium 4, so of course it has SSE (this target is ancient, it predates Rust 1.0)
- i586-pc-nto-qnx700 uses Pentium 4 as baseline (resolved by Make x86 QNX target name consistent with other Rust targets #137324)
- i686-unknown-hurd-gnu uses PentiumPro without SSE as baseline (resolved by i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4 #136700)
- i686-unknown-redox uses PentiumPro without SSE as baseline (resolved by Replace i686-unknown-redox target with i586-unknown-redox #136698)
If we want to establish the pattern that "i686 has SSE and the rest does not", then the last four of these should be renamed. (These are all tier 3 targets.) I wonder if there is a specific reason that these names were picked diverging from our usual naming scheme, or is it just an oversight because our naming scheme is admittedly not very self-explaining?
- The Apple target is ancient and I assume was picked for consistency with how Apple calls this -- not sure if that should overwrite our own naming scheme.
- For Hurd and Redox, we have no other targets that use PentiumPro without SSE as baseline, so it's a bit unclear what one would even use -- they are somewhere between
i586(original Pentium) and what we calli686(Pentium 4). The most consistent outcome here would be to use Pentium 4 as the baseline like we use for all other OSes; not sure why Hurd and Redox should be special. - The
i586-pc-nto-qnx700one however should almost certainly be calledi686.
Pinging the listed target maintainers and some other folks:
Cc @bjorn3 @workingjubilee @badboy @deg4uss3r @madsmtm @sthibaul @jackpot51 @flba-eb @gh-tr @jonathanpallant @japaric
Activity
jonathanpallant commentedon Feb 3, 2025
For QNX Neutrino 7.0.0, that is the name that Blackberry QNX use for their C toolchain:
~/qnx700/host/darwin/x86_64/usr/bin/i586-pc-nto-qnx7.0.0-ldI think the primary question you all need to ask yourselves is:
rustc), or is it better for each target be consistent with other toolchains for that targetI've already had this argument about arm64e-apple-darwin (which in my view should have been aarch64-apple-darwin-something), and I lost. But maybe you'll have another ticket for the Arm 64-bit targets.
RalfJung commentedon Feb 3, 2025
I was wondering about the
arm64eprefix... but I didn't plan to check all our targets, now. I am too scared of what I may find. ;)bjorn3 commentedon Feb 3, 2025
arm64ec-pc-windows-msvc is similar in weird naming, though it's behavior is much less cursed than in C where it literally makes target detection using macros think it is running on x86 with x86 vendor intrinsics emulated by the compiler.
sthibaul commentedon Feb 3, 2025
I don't remember the details, but basically we targetted i686 as defined in Debian:
https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
(and also gcc)
? That would assume SSE2, which is wrong? #82435 (only pentium-M has SSE2)
Adding MMX and SSE should however be fine enough, even if the very original pentiumpro didn't have them.
workingjubilee commentedon Feb 3, 2025
Debian also advises that you not use a CPU less than Pentium 4.
sthibaul commentedon Feb 3, 2025
This is just a recommendation.
Debian can actually be used on way less-powered i686 systems if you stick to a minimal system. But you cannot expect to be able to do what you were used to be doing 20 years ago with the Debian distribution at the time: code has gotten much larger.
workingjubilee commentedon Feb 3, 2025
sthibaul commentedon Feb 3, 2025
workingjubilee commentedon Feb 3, 2025
For note: Currently, the Debian-distributed rustc patches our i686-unknown-linux-gnu to use Pentium Pros instead of Pentium 4s. This results in them getting bugs and test failures in Rust code because the code generation doesn't use SSE2 registers, thus is unsound due to various bugs in LLVM (and while I am told GCC is better, I'm not entirely sure). They then report this to crate maintainers. The crate maintainers, having deliberately developed against i686-unknown-linux-gnu as per rustc's definition, get very confused. They then get annoyed, when they find out this is entirely caused by Debian's insistence on divergence from rustc's definitions.
Unfortunately using real CPU names in targets like perhaps
pentium4-unknown-linux-gnudidn't catch on, and neither did tuples likei786-unknown-linux-gnu(even if they are technically recognized by Autotools).sthibaul commentedon Feb 3, 2025
You mean caused by rust's insistence on assuming that i686 has SSE2.
44 remaining items
RalfJung commentedon Feb 13, 2025
RalfJung commentedon Feb 13, 2025
I re-added the nomination, to answer the very concrete question of what to do with i586-pc-nto-qnx700, a target with a Pentium 4 baseline. We typically use i586 to indicate "older than i686" (with i686 meaning "Pentium 4"), so there is a direct conflict here between the vendor convention and our own convention, which will easily be confusing for Rust users.
apiraino commentedon Feb 20, 2025
@jonathanpallant it seems that @flba-eb suggests that
i586-pc-nto-qnx700could be a "good enough" candidate. Am I reading correctly that you don't have a different opinion or alternate suggestions?RalfJung commentedon Feb 20, 2025
To be clear the new name would be
i686-pc-nto-qnx700; that would be consistent with out otheri*86targets.Rollup merge of rust-lang#137324 - flba-eb:rename_qnx_target_name_i58…
Rollup merge of rust-lang#137324 - flba-eb:rename_qnx_target_name_i58…
Unrolled build for rust-lang#137324
jonathanpallant commentedon Feb 21, 2025
It was merged before I had a chance to comment (unlike the PR that added it, which I recall took months to approve and merge). But yes, I have always said Rust should prioritise internal consistency over external; this change does that and I support it.
RalfJung commentedon Feb 21, 2025
Ah, I hadn't even seen #137324, nice. :)
That makes i386-apple-ios the only remaining culprit. The vibes given by @madsmtm were that this target will anyway be removed. Is there a timeline for that?
madsmtm commentedon Feb 24, 2025
Not really a timeline for it, no. If it's important to you, I'd be fine with renaming the target in the meantime (if so, it should be renamed to
i686-apple-ios-sim).RalfJung commentedon Feb 24, 2025
Not very important, no.
apiraino commentedon Feb 27, 2025
Last question about target names should be addressed in comment (iiuc)
Comment also provides a rename suggestion for
i386-apple-ios.@rustbot label -I-compiler-nominated
Fabian-Gruenbichler commentedon Apr 2, 2025
I missed this, but just wanted to add two more references for people stumbling on this via the rustc release notes ;)
Debian will most likely switch to i386 including SSE2 after the next stable release is done (the whole issue came up too late in the release cycle to make the cut for Trixie, which is already partly frozen by now):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095862
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095863