lang/rust: enable SSE2 by default on i386

[asomers]

Summary

Upstream Rust always requires SSE2 for x86. But back in 2017[^1][^2] we
patched lang/rust to disable SSE2 for i386. At the time, it was
reported that some people were still using non-SSE2 capable hardware.
More recently, LLVM bugs have been discovered[^3][^4] that can result in
rounding bugs and reduced accuracy when using f64 on non-SSE hardware.
In weird cases, they can even cause wilder unpredictable behavior, like
segfaults.

Revert our change for the sake of Pentium 4 users. But add an SSE2
option. Disabling it will allow the port to be used on Pentium 3 an
doler CPUs.

[^1]: https://github.com/freebsd/freebsd-ports/commit/d65b2886b1b3b2135f0b8982de4d9754517acf61
[^2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223415
[^3]: https://github.com/rust-lang/rust/issues/114479
[^4]: https://github.com/llvm/llvm-project/issues/44218

[emaste]

This is fine with me (but I'm not a ports committer). We ought to give a heads-up as well - your commit message captures the appropriate detail, so I'd just post that to appropriate mailing list(s).

[emaste]

As @fuz mentioned on IRC, we should also add a note in UPDATING

[asomers]

• add an UPDATING note

[jbeich]

But add an SSE2 option. Disabling it will allow the port to be used on Pentium 3 an doler CPUs.

Bootstrap uses SSE2, so the port won't build on such old systems. Converting to a flavor may help but lang/rust itself may remain unbuildable unless the bootstrap is flavorized or an existing installation can be used as bootstrap.

UPDATING

9 ↗

(On Diff #145317)

pkg-updating(8) requires AFFECTS to contain package origin (aka port category/name) or magical phrase (currently unused by UPDATING).

[asomers]

In D47227#1076964, @jbeich wrote:

But add an SSE2 option. Disabling it will allow the port to be used on Pentium 3 an doler CPUs.

Bootstrap uses SSE2, so the port won't build on such old systems. Converting to a flavor may help but lang/rust itself may remain unbuildable unless the bootstrap is flavorized or an existing installation can be used as bootstrap.

This new option doesn't affect bootstrap. So the port must've been unbuildable on PIII for a long time. That probably means that any PIII users who use Rust are using some other machine to cross-build their packages, which makes sense.

UPDATING

9 ↗

(On Diff #145317)

I don't want to put 500 separate ports on the AFFECTS line, so I guess I'll go with "all users". I do however see some entries that don't conform, like 20240529: "users of python".

[asomers]

• Respond to @jbeich's comments regarding UPDATING

[jbeich]

This new option doesn't affect bootstrap.

lang/rust uses lang/rust-bootstrap instead of vendor binaries, so changes (like codegen) to the former affect the latter. Upstream has stopped providing anything but rust-std for i686-unknown-freebsd many years ago i.e., there's no vendor bootstrap for i386.

using some other machine to cross-build their packages

Like the FreeBSD package cluster? With port option the affected users will have to buy/borrow a dedicated machine separately. And if not routinely tested by the maintainer or automation the option will bitrot.

[asomers]

In D47227#1076997, @jbeich wrote:

This new option doesn't affect bootstrap.

lang/rust uses lang/rust-bootstrap instead of vendor binaries, so changes (like codegen) to the former affect the latter. Upstream has stopped providing anything but rust-std for i686-unknown-freebsd many years ago i.e., there's no vendor bootstrap for i386.

Even so, lang/rust-boostrap is ONLY_FOR_ARCHS=amd64 powerpc64 powerpc64le . It's got a flavor for i386, but I guess that is just for cross-compiling? If so, then rust-bootstrap won't run in fewer places after this commit than it does right now.

using some other machine to cross-build their packages

Like the FreeBSD package cluster? With port option the affected users will have to buy/borrow a dedicated machine separately. And if not routinely tested by the maintainer or automation the option will bitrot.

Yes they will. Pentium III will basically be treated like an embedded system now.

[asomers]

As Jan pointed out, this change will hurt the experience of PIII users. But it will improve the experience of P4+ users, and x86_64 users with 32-bit jails. So @emaste @jbeich , is that a good enough reason to commit it? Or do we need to canvas more people?

[jbeich]

I still feel the port option is not practical (waste of CPU time and electricity) but otherwise have exhausted my arguments. It's up to rust team to actually approve but "maintainer timeout" (14 days) may also work.

In D47227#1077102, @asomers wrote:

Yes they will. Pentium III will basically be treated like an embedded system now.

Like Tier3 without packages? armv6 and armv7 have separate repos, so a rare armv7 CPU without NEON can still use armv6 packages (EDIT: until 988dc662364d).

[jbeich]

UPDATING

17 ↗

(On Diff #145328)

build -> cross-build. Native builds won't work on SSE2-less hardware due to bootstrap.

[jbeich]

UPDATING

17 ↗

(On Diff #145328)

cross-build example:

now cross-build lang/rust for i386 on amd64 via ports-mgmt/poudriere after disabling SSE2 port option, and rebuild

[asomers]

At the 2024 FreeBSD Summit we took a poll. Not a single user thought it important to continue providing Pentium III-compatible prebuilt packages. So I'm going to commit this now.
{F102272979}