XPost: linux.debian.devel.release

[individuals stripped as recipients, as per Debian mailinglist policy]

Quoting Fabian Grünbichler (2024-11-23 15:14:42)

p.s.: if you become aware of such an issue with any toolchain, it
would be nice to file a bug report *with the corresponding toolchain
package in Debian* to make its maintainer (me in this case) aware as
well. we could have had 2-3 months head start on tackling this issue
if you had done so..

Duly noted. Sorry!

I genuinely thought that I had not uncovered a new bug but simply
noticed yet another case of the Rust team approaching Debian in ways
unusual to me but in principle not wrong nor broken nor buggy, and
therefore only a reason for filing bugreports if I wanted to be annoying
which I don't.

I shall try to be more noisy in future.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============�55435746346115994=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnQejDCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmcoQMJ8XsxDvQ76s0tBPasx0J3qEar+jpF/ZMsswVVD nxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAAt4Q/+IIIKnc516NMYqhDrPl0Bf118 OIehtyZPXO0rosE1SlqvfQffpNIe2mJlYx8PPgjnH8hEmvpPxy0cFgbVMdGP+Z/I SyRNsqFW4ibJoNcHZ0Wu8n9eY5HpnEekAP/e80u6HHsypX/yElbztl5viJ2jbH3o PrQJgrz8uvUYfQwMH9oGmn3omaLN1r2lHIOwgMAzGv0ME9Yg68rQldN/Ho9NBX9S W4+FXXVOXwXd9bJOZ0dXDV5x956yHnoKY0Jn6I8mHdNSIQTxbLiTlRs1mD5m5N5H NToW7nuKGaRNnsfjE6Bp0ZktNceMORvYpGRQWYLcxa6GRr5hTV1nS1s0lJPBw1WB nWuOcSQV58Shq1HWCn/paIPtDStqAVW4fLBM3VyV

XPost: linux.debian.devel.release

On Sat, Nov 23, 2024, at 1:09 PM, Jonas Smedegaard wrote:

Quoting Chris Hofstaedtler (2024-11-23 04:16:29)

* Jonas Smedegaard <[email protected]> [241122 18:01]:

All release architectures support Rust. We should not accept
release architectures without Rust support.

A minor set of ports architectures does not have Rust support
yet.

Rust is unsupported on i386 and patched to silently assume i686

i686 is not a problem, as that's the arch baseline for our i386
arch since bookworm.

yeah, this is not related to that particular change, but to this:

https://wiki.debian.org/ArchitectureSpecificsMemo#i386

in combination with a bad interaction between rustc and LLVM..

- see
DEP-3 references in this patch for discussions about that, and the patch >> > itself for a way to more loudly make reverse dependencies aware that
code using SSE2 *must* be compiled without optimizations on i386:
https://salsa.debian.org/debian/rust-wide/-/blob/debian/latest/debian/patches/2001_fail_non-sse2-x86.patch

Beware that Rust team build routines run tests without optimizations,
regardless of DEB_BUILD_OPTIONS=noopt, so for libraries maintained by
them the issue may go unnoticed until reverse dependencies run into the
issue *and* test for it, otherwise it might go unnoticed until users
report it.

So maybe it's time to raise the baseline to i686+sse2.

As I understand the situation with Rust, it is *not* that compiled code
fails to run on old non-SSE2 hardware. Instead, the problem is that the
Rust compiler produces code that is *ALWAYS* broken regardless if target hardware supports SSE2 or not.

Yes, your final remark is a "solution" regardless, I just wanted to
emphasize that the problem affects the whole architecture, not only
outdated parts of it.

...unless I have misunderstand the situation, obciously.

AFAICT, this seems to be true. I was (so far) under the impression so far that this only affects FP arithmetics (i.e., the usual issue one runs into this is test code that does FP operations and then checks that the result is as expected). given that it'
s not limited to that (see https://github.com/rust-lang/rust/issues/114479#issuecomment-2072052116 and https://github.com/rust-lang/compiler-team/issues/808), the situation is a lot worse!

so yeah, I guess we should either

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

one downside of the i586 approach is that its not a tier 1 target upstream, but a tier 2 without host tools one, similar to armel or mips64el. that means both less testing upstream, and no prebuilt stage0 for (re)bootstrapping, which makes jumping
versions more involved. this might affect things like cargo-web/rustc-web on stable, or the ability to quickly catch up with upstream if we lag behind version wise.

both A) and B) are rather invasive changes.. if the RT (CCed) has a strong preference I'll of course follow their lead in this matter. otherwise, I'll see how involved the changes for A) are and maybe upload a build of that to experimental in the next
week, so that we can do an archive-wide rebuild and see whether things break.

p.s.: if you become aware of such an issue with any toolchain, it would be nice to file a bug report *with the corresponding toolchain package in Debian* to make its maintainer (me in this case) aware as well. we could have had 2-3 months head start on
tackling this issue if you had done so..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

* Fabian Grünbichler <[email protected]> [241123 15:31]:

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

D) follow the other teams and stop building Rust on i386.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sat, Nov 23, 2024, at 3:14 PM, Fabian Grünbichler wrote:

On Sat, Nov 23, 2024, at 1:09 PM, Jonas Smedegaard wrote:

Quoting Chris Hofstaedtler (2024-11-23 04:16:29)

* Jonas Smedegaard <[email protected]> [241122 18:01]:

All release architectures support Rust. We should not accept
release architectures without Rust support.

A minor set of ports architectures does not have Rust support
yet.

Rust is unsupported on i386 and patched to silently assume i686

i686 is not a problem, as that's the arch baseline for our i386
arch since bookworm.

yeah, this is not related to that particular change, but to this:

https://wiki.debian.org/ArchitectureSpecificsMemo#i386

in combination with a bad interaction between rustc and LLVM..

- see
DEP-3 references in this patch for discussions about that, and the patch >>> > itself for a way to more loudly make reverse dependencies aware that
code using SSE2 *must* be compiled without optimizations on i386:
https://salsa.debian.org/debian/rust-wide/-/blob/debian/latest/debian/patches/2001_fail_non-sse2-x86.patch

Beware that Rust team build routines run tests without optimizations,
regardless of DEB_BUILD_OPTIONS=noopt, so for libraries maintained by
them the issue may go unnoticed until reverse dependencies run into the >>> > issue *and* test for it, otherwise it might go unnoticed until users
report it.

So maybe it's time to raise the baseline to i686+sse2.

As I understand the situation with Rust, it is *not* that compiled code
fails to run on old non-SSE2 hardware. Instead, the problem is that the
Rust compiler produces code that is *ALWAYS* broken regardless if target
hardware supports SSE2 or not.

Yes, your final remark is a "solution" regardless, I just wanted to
emphasize that the problem affects the whole architecture, not only
outdated parts of it.

...unless I have misunderstand the situation, obciously.

AFAICT, this seems to be true. I was (so far) under the impression so
far that this only affects FP arithmetics (i.e., the usual issue one
runs into this is test code that does FP operations and then checks
that the result is as expected). given that it's not limited to that
(see
https://github.com/rust-lang/rust/issues/114479#issuecomment-2072052116
and https://github.com/rust-lang/compiler-team/issues/808), the
situation is a lot worse!

so yeah, I guess we should either

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of
the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling
SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an
option I think, just here for completeness sake)

read the full upstream issues now - downgrading to i586 doesn't solve the issue at all, upstream just doesn't care about it there because that target is not part of their fully supported tier.

so that means option A) is effectively off the table (other than we save ourselves some further patching once the "don't allow to disable SSE2 on i686" patches hit an upstream release), and just leaves B) if we want to really solve it, and C) if we want
to do an incomplete hacky papering over.

selected quotes from the GH issues linked above:

GH user beetrees at https://github.com/rust-lang/rust/issues/114479#issuecomment-2207770946 wrote:

The unsoundness is not just theoretical; the LLVM IR Rust compiles f32 and f64 operations to has the desired Rust semantics, whereas the LLVM non-SSE x86 backend compiles that IR to machine code that violates the semantics of the IR. This means e.g.

LLVM optimisations that (correctly) operate presuming the LLVM IR semantics with regards to evaluation precision can cause the LLVM non-SSE x86 backend introduce out-of-bounds reads/writes in safe code (see this earlier comment for a code example). The
NaN quietening issue also violates the semantics of LLVM IR and can cause the emitted binary to mutate the value of non-float types (see this earlier comment for the code sample, details in this comment).

Because this is a miscompilation at the LLVM IR -> machine code stage, as opposed to the Rust -> LLVM IR stage, miscompilations can occur in other programming languages that use LLVM as a codegen backend. For example, llvm/llvm-project#89885 contains

an example of a miscompilation from C. Ultimately what matters are the semantics of the LLVM IR; not everything that is permitted by the IEEE 754 specification is permitted by LLVM IR (and vice versa).

The return value ABI issue is tracked separately in #115567, and affects all 32-bit x86 targets, not just those with SSE/SSE2 disabled. It is possible to manually load/store a f32/f64 signalling NaN to/from an x87 register without quietening it (see e.

g. the code in #115567 (comment)), but currently neither LLVM nor Rust do so. The "Rust" ABI (which doesn't have any stability guarantees) is being changed to avoid x87 registers completely in #123351.

GH user RalfJung at https://github.com/rust-lang/rust/issues/114479#issuecomment-2208193457 wrote:
As @beetrees explained, it's not just that the underlying hardware works differently and that bleeds into language semantics. It's that Rust's primary backend, LLVM, assumes the underlying hardware to work the standard way -- the examples @beetrees

referenced demonstrate that there is no reliable way to program against this hardware in any compiler that uses LLVM as its backend. (At least not if the compiler uses the standard LLVM float types and operations.)

To my knowledge, nobody on the LLVM side really cares about this. So until that changes it is unlikely that we'll be able to improve things in Rust here. Telling programmers "on this hardware your program may randomly explode for no fault of your own"

is not very useful. (I mean, it is a useful errata of course, but it doesn't make sense to make this the spec.)

so this is actually an LLVM+x87 bug, not limited to rustc, and not limited to Debian's rustc variant either, it's just that upstream's i686 rustc doesn't disable SSE2, whereas ours (and upstream's i586) do, and thus expose the issue. I tend to agree with
upstream that the *only proper* solution is to enable/require SSE2.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Quoting Chris Hofstaedtler (2024-11-23 17:50:25)

* Fabian Grünbichler <[email protected]> [241123 15:31]:

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

D) follow the other teams and stop building Rust on i386.

And that would leave i386 without mesa and python-cryptography both of which not only have an extremely high popcon but are also the dependencies of some other rather important things...

I know you know, just for the casual reader. :)

cheers, josch
--==============w67746635061944778=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmdCEPkACgkQ8sulx4+9 g+HWJw//abjnfnqWe1PckQNknUKNbJ55lv0/YehhGH2uFZYVLhVnLJ1/ytVYaSWn HL43mH9dq4Xc6sFPINQuClW4MdoQKu8RQHdIeoD1wBOlAGY9j0tI0CMGE7xLzoXh lG3197qXcAC/UqsfWC96VSeJEkobcEf6gGkPcVi5kTbuKIpLukxAWlqtA9OdZaRe AytXRj2HvrzMYRV0s8ATHasRtyBO26VkPSTpEWCg+CPpEgocSS7VWa7EL6sBPi4U ILuHQ212mrLgoFqLNnw8CpUoFhtuAslBiskI99egWOvNvv/4i+dVZzFg+xfzRhfv wSSLcCav+YB4t+iI0fOxsidTckHf9HLbRZLrqb8N0iakXEA/ckFjOqgZjfYAL6P1 MzZwoWOQOHZ3QgNBFfDxIFwBAIPvVaZ2HSA6UCnCrwkrNzgj2YsWDhjTF/6At6KA 0i2P3QDH+syJprbXRBTt31atSmLt3hluIhBJBC8PXcSZYjnQXTiUIn3nZXTJzWZF Y9kML2Bj3AzQek5+89jFgCpBi34z5QLY7udPhiIhYq4Wyt61Ur+jzg8uGzbMcSP6 U5AvSG4qlJ+J48KoTjct+8ach7Lugse+tKUIbOBU4WnYIBxjXm+PApn2vTe6HfXG keOMOP+EHYiHkQUHUF0xJsjeg2GMQgO/N7QJQt3THKRR1KTnR/E=
=tN16
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected]

Le samedi 23 novembre 2024, 18:29:04 UTC Andrey Rakhmatullin a écrit :

On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround thus FTBFS

Bastien

As suggested by Chris, and a popular opinion/request in general.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdCJVAACgkQADoaLapB CF/JwQ//bVDtiwn+y3WiGtW67+BDSDhN8WfmqBZMKZIg+cntjkRAoDs2q3nj4GN1 H+ySialCqhqY3LDhwu4FC6ap+Y53i9Wp+biLwc4aGXwHA19cqZrmjG5b8tYJ9hc9 NmZsBX8t2fE+P54lR25OlhcxmShXVIjOcyWizyJ8KnGuQpswfMkh8W+4mtYt3uNn XCK3rEnuWixBQIFR9247ac5ts/D7bZM3LQvh9xsJSS9afH2j5p21lSWtpb3acncb 3V9mgCLSvIZsf6UfkBWyG9tSaYzBWY2ZFW36a3ZsKfRuvM3bbzQoQhQQL9geLnfv Y1kLANgmLThXbuLC4F0GFm4O61KRb+RNgPblSKpdp1JKLvwILxyZEG8/UJfpUWPD 45fX4nthwn43TkTvAf7LpLc4Uxo1WJn/R8IJa5KigHQXHcPCmF220tuIzgV4vIWy VMyr4KxB/q3WA87f7WySq5nc9TQflAE540hKdepBZuqyB0gwkAjDt8Tj+Tab6f8M pMnFBPRiBcoz4Ecr6mB6gSis5L3tHiKUZyJIjmSOMGVenNLv8aTJEdmiVx5QGvNK uV1Jhsjf1cYhjlv/XF9hrJXxlwwWApJEQ5Qh1ddmfTZLFMPhSrYGTb+jK1ezH8UF geKsk+2l1LBLwlfgTD3JJs7fXdbt/SNvHBK99MzK7WwFS3HFT9E=
=YL0s
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

As suggested by Chris, and a popular opinion/request in general.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdCHvAtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 21oQAIUN6bZ0B7/NyewcueknNBxdI2Zdgfy41x3YhyuN4nBHI+b18BgVtKZLHlxx lv4Ipoo1RSWxIhUK9oBtGNDw/WRAasEeReZG/r3UAnA2eCOidJm/kk7fUGjBdBqp 2eRdFmjMghDBesnJo+7hWOqnmclce+mQgcwZuYBabdue8Uo10Hj8zcD/GB7gGcZi UTg8JN9dOiXEwNIw3QHcCRioUr1rNkD8Sx0v63fdeBfKPaP71x8GyVSFU4+ilhcR MtjH8ZKeTO5IivruB+CfTxeNB8QP99d5e4L/eKfzM8fwaHCubZfCPTsZWEC4bOMk KQznagAuCIHDAI/OE66Mi67WL6ARrp9QioVqTDGFO+lQTlptRqpvNF2nwnVEFlVi dAIjh7L0fMEwhT4KCrvNpnjiBDo2k7rkwSU+MSAPMu9Z3TyYSitypyptt7hJl2AZ LshE2E6TQ7KyOpP6+vhzqA8Rcza/ljmo7cvRqPZ1JnP09GOWnrpx2QL1DnMr8fp9 Z4OhwOhUesMPWybBH6DSKiQALp2nzYKg6LERGxZabfpkWw14CUdJQUg3RpdmDcD6 T8oXppxY4cx65aOdl0nw1QV+B/DeR1raH8RdhMYZy5lQpWWX9ZOdR6/5IV/aIRi1 FuLedlSTBMSeBy8asBMbP4g7uM7jNa5iT1NlEjYHW6gC1C5D
=7cVI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 23, 2024 at 1:57 PM Bastien Roucariès <[email protected]> wrote:

Le samedi 23 novembre 2024, 18:29:04 UTC Andrey Rakhmatullin a écrit :

On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround thus FTBFS

Debian's i386 already has excess precision: https://wiki.debian.org/ArchitectureSpecificsMemo#i386

If you mean something else, could you be… more precise?

Thank you,
Jeremy Bícha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On November 23, 2024 9:03:26 PM GMT+01:00, "Jeremy Bícha" <[email protected]> wrote:

On Sat, Nov 23, 2024 at 1:57 PM Bastien Roucariès <[email protected]> wrote: >>

Le samedi 23 novembre 2024, 18:29:04 UTC Andrey Rakhmatullin a écrit :

On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround thus FTBFS

Debian's i386 already has excess precision: >https://wiki.debian.org/ArchitectureSpecificsMemo#i386

If you mean something else, could you be… more precise?

Its very much possible that things relying on x87 floats on i386 will need to adapt if some underlying implementation switches to SSE, just like the inverse happens now (like testsuites expecting SSE behaviour/results that need to be adapted to x87).

I don't think that is a problem per se. And you can still use x87 floats if those work for your package, even if we go down that road. Well not with rust, but given that those are apparently broken already anyway...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le samedi 23 novembre 2024, 20:03:26 UTC Jeremy Bícha a écrit :

On Sat, Nov 23, 2024 at 1:57 PM Bastien Roucariès <[email protected]> wrote:

Le samedi 23 novembre 2024, 18:29:04 UTC Andrey Rakhmatullin a écrit :

On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround thus FTBFS

Debian's i386 already has excess precision: https://wiki.debian.org/ArchitectureSpecificsMemo#i386

If you mean something else, could you be… more precise?

if SSE2 is enables gcc will not use i387 thus i386 will loss excess precision and have double like amd64

i387 => excess precision
SSE2 no excess precision

Bastien

Thank you,
Jeremy Bícha

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdCO30ACgkQADoaLapB CF8mlA/+OKTMjn1pUesBTExJopYecT8R/B4073gIUjsfLFEP9pOhgmXx9UKb+A55 f9cQDlFb7K7ABfevcJ4PgsirF7dMhCf7esqxkvOwmY69tJ66tB7Tvtj+UOvGUE30 2d2riNT2TCPnX8sbsg05UxYZDY8qSkru8yrSYLPcdt45D+9Tt61bmluRYgKYaj1y IDmRIMSATpuH54B+5y0BXiCSlffrb8rctM716btfvImwIbfH0B9dENVk193iKt0R 4Hi1fy+OXPMYLsb/ZFzXmi8T6x5Q/tWl4p6lu2x3vM6xwszRispZhPWGi6Um8dYK 0VpOWKuqeuV1Mhhlls246M/7hllq9u6CaMWy3LVQd2i53nu/CjBVvXU8Zv0/r6kx YzL47YM686eiTNmA4vbjhf0RiCAbLu4/tyxTILxk9vv6t0FUpzDxq6CgV2h0RBA4 AI/xoD9UaeU0DEwIRm0kyJHbEwf8Uc0Z10HlMMVWhtu/wH+RJKBrsLpCef7A8n1J H31Kj6G4tP44z/QKUX0p7X726OjegXHOWhMncBATq+2K8x64FCd/Xkygnpq6+hvX B4p7PPZJkGNeG7GbmoFQhAaN1E0/u/bQk1JapN+eguWg0KXf4n3kxpB0Rh7VqQ6Z 7so258SDRdgoIicXEGKl6iWIYIU85EILu1i7vqfk1oZOEVRPEqg=
=AZSe
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected] (Fabian =?ISO-8859-1?Q?Gr=FCnbichler?=)

Le samedi 23 novembre 2024, 20:20:31 UTC Fabian Grünbichler a écrit :

On November 23, 2024 9:03:26 PM GMT+01:00, "Jeremy Bícha" <[email protected]> wrote:

On Sat, Nov 23, 2024 at 1:57 PM Bastien Roucariès <[email protected]> wrote:

Le samedi 23 novembre 2024, 18:29:04 UTC Andrey Rakhmatullin a écrit :

On Sat, Nov 23, 2024 at 03:14:42PM +0100, Fabian Grünbichler wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround thus FTBFS

Debian's i386 already has excess precision: >https://wiki.debian.org/ArchitectureSpecificsMemo#i386

If you mean something else, could you be… more precise?

Its very much possible that things relying on x87 floats on i386 will need to adapt if some underlying implementation switches to SSE, just like the inverse happens now (like testsuites expecting SSE behaviour/results that need to be adapted to x87).

I don't think that is a problem per se. And you can still use x87 floats if those work for your package, even if we go down that road.

In theory yes. In practice I do not know, I am quite unease to x87 passed to sse due to library then passed back to main program...

It will give us some interesting result

Well not with rust, but given that those are apparently broken already anyway...

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdCT8QACgkQADoaLapB CF8EEw//RK+AtFkBFUDgHitFg9OxRlGi8bFRx3r47tmJJv4nA9XpQKmECF6hJIvO yvuCAPcUNyQCF1BXI4e6vnLEKVdNaUbciVeFB2P2qrh2eyXJ8MurMQatSRcnEWdo 5a5BQJoDDohSlJv5wvbuSGksDWdhjzSKnkYG9Wx9JnFq8lYKCOkrsxoRqVwOsjk8 W0seHIoJ5DH56tWPl9xtEXV0XBJxsdtkYX+5RQH0OAWaLaPWCnmEGjPC2ZgHAO4s bDCiG9lyjsklH5bFmtOAOgca3SzztGBmc30bI5VyVZxq90zkKiWYIIsI3ygrGdhN ihA0R/I00ClWkYLUM3EOl6EWVluZcZApD8xZFFF9VgpsCLwLAwb5MdY/kETXlG4b ewLIgtTcWbOw+to0X24wlqSLZbyMFMgNUJ3evbYp6bTGfCxhfH4J22aWTANN6utR 2diO70lCRZQZgBG6Tanya9SBzBi2dqn7ht1OceAxhnrH+9Rgm8E5S2eTAsRAUpxZ 1y8zF/mD84HCmNnT9GSpKw6fxup7/v5EEQdz3imcHyBOOm+6Ol+/sdGOV2vbASbJ HnoPqgj8wJcaglO8mtwI581YO7hRM/JxGqy37UTIgYvgx3uF3iRlgARC7/bIvzhN FrLdxIFHhyEPJyEwnbZjMAmFNfmNZKpbegld7bZdQoWrLCgozh4=
=61Uh
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sat, Nov 23, 2024 at 10:30 PM Fabian Grünbichler <[email protected]> wrote:

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

For reference, golang had a similar problem 3 years ago[1]. We decided
to downgrade the baseline for golang on i386.

[1] https://lists.debian.org/debian-devel/2021/04/msg00165.html

--
Shengjing Zhu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 23, 2024 at 08:31:15PM +0000, Bastien Roucariès wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround thus FTBFS

Debian's i386 already has excess precision: https://wiki.debian.org/ArchitectureSpecificsMemo#i386

If you mean something else, could you be… more precise?

if SSE2 is enables gcc will not use i387 thus i386 will loss excess precision and have double like amd64

i387 => excess precision
SSE2 no excess precision

Which is a good thing normally.
Just remove the workarounds you mentioned.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdC1V4tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh o+AP/iDlLoQHLz6p8IPcDre5QAJEObtv3HT6KSRGj/PZ9C5aqDC7s7+ltjoG0oav J1jHdqga3CUY+UfFDFBOAiFU12O60HkYw9PE/u/UqR2U1L3WYjH/A1tgXZomsOkg Rc1la3vI9H12rnsudUazTOCCJBHaA6csiEB8Nk8eZQkfRdgsey6O9utNGCzTyF0Z miPN9GXfI+8q7axvGNx6TmzDpJX/5tzXmdNtA4br8Ek4mqBtSr/wNVwrIno8dMIf e09avyzm68ch/lthTacIQrI1exO6EZXh36dXDH/C23H9Wi50E+57AVXNAEuEB6uo NziYjKAqL+BB/0x/xD99BxYNNj0VoiqFsV2roVRKHY1wlCiVcoeP6rFyjmLIs6VX IPYZN7TT46LZJ+0+I+HGg/EbuKME+H6c7kCBtXjyxLTKJ4weJep0TdZhNoS1V29A RfEpSjwD/DZbHqttD84+n9zdiuFkHzvgD4YdIlFIGpYQYN2je+XOixyFxz9pQJ2e yxZukkJu5NbIY48c/OmW+Hn+fIsGGPSgmq82CQ4zVGwmfnfD584BXpHcoUy/GhBK PkC5TKGaJi9HKvoF3c8ynurlz6bX2rDlOSnT9LtZaXQ8gAyb1Z5NlByWtUCjE9Iu KlDIzqLJSAoNI2k3XJrfqhKrR43Yab2OvdIAaCRo2G0YNKSi
=DehK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sat, Nov 23, 2024, at 5:50 PM, Chris Hofstaedtler wrote:

* Fabian Grünbichler <[email protected]> [241123 15:31]:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

D) follow the other teams and stop building Rust on i386.

I am not personally invested in i386 at all, but that is still not a call that I'd want to make as toolchain maintainer. If the release team prefers it over B) and over risking running into the miscompilation issues in practice, then I won't object.

FWIW, my (personal!) current preference would be B), followed by either documenting the issue and accepting it or D). Given the far-reaching implications of both B and D, I don't think this is a decision that either I or the Rust team can make alone.

And as Josch indicated, dropping Rust from i386 would remove quite a lot of packages/affect quite a lot more teams than just the Rust team.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sun, Nov 24, 2024, at 8:01 AM, Shengjing Zhu wrote:

On Sat, Nov 23, 2024 at 10:30 PM Fabian Grünbichler <[email protected]> wrote:

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

For reference, golang had a similar problem 3 years ago[1]. We decided
to downgrade the baseline for golang on i386.

[1] https://lists.debian.org/debian-devel/2021/04/msg00165.html

downgrading the baseline for Rust is what got us into this mess ;) there is no 32-bit x86 softfloat target upstream. there is a 64-bit one for kernel/.. usage: https://doc.rust-lang.org/beta/rustc/platform-support/x86_64-unknown-none.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Le dimanche 24 novembre 2024, 09:54:18 UTC Fabian Grünbichler a écrit :

On Sun, Nov 24, 2024, at 8:01 AM, Shengjing Zhu wrote:

On Sat, Nov 23, 2024 at 10:30 PM Fabian Grünbichler <[email protected]> wrote:

A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the box), instead of the i686-with-SSE2-disabled it currently uses
B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

For reference, golang had a similar problem 3 years ago[1]. We decided
to downgrade the baseline for golang on i386.

[1] https://lists.debian.org/debian-devel/2021/04/msg00165.html

downgrading the baseline for Rust is what got us into this mess ;) there is no 32-bit x86 softfloat target upstream. there is a 64-bit one for kernel/.. usage: https://doc.rust-lang.org/beta/rustc/platform-support/x86_64-unknown-none.html

How much effort it will be to use SIMDeverywhere on i386 ?

https://wiki.debian.org/SIMDEverywhere

Bastien


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdDALQACgkQADoaLapB CF/tdw/8C/7XgxElX3PcQF1HhFZfRokNQCSCK5d2Dbd4d4IQxKdnxmaypBUHcpdY 4FGj6ZeMTeSrb/jsGJ10cxNtHmYn+RnQYOhUJDss8kPVOIYJH464W8s4YQKOzC2N oFRlxfB+eIWHWkCL8HOHZ/0GoIbUFEjaWomeOD03Ve0cXitTYVgpaFqGQzbBh/dt y/OzoltwFE6LxajhK6BOsiT3pVr1YH+fVMUXp0P/OMb47ysawfzkZ1MDyOwV7qMm yOBJoM/RfMMlemR1fS+hVOD2Vs97WbVZcviK2j3LL5CeguK4qst7HkJoxZ0J03ng n8f503eATzO+mtmLTmQoayd5qvJe2HK6Ov9ul0W9U9cV31EYVDnVKxi5DkK+Ehb5 lAOX+GIwscql+tWg6Fv+mKbI5qpnBTEA+33jEBMmElST1oduz1sofgtNUHtDr5a6 9u4uXEHNka07hCLNhtyb7dnfK4KRspL8mVwBd/CcVQxMiDZJChl9s8FlxsYFrjJ6 5yEAO4yLalUTdUtaN1qsfQ0/ZibjVytMxTwG5Eq2dJ/SMqdpzWq/EalPtBX4mMSw DKPVIheOraJceOsTcaw8k/7PcO0OrlU1rmI+CEZZVNSsblCRTFzDGjZ3RxzqHB+W ozAQ8LO2X6SfFfv/vLpM1rCXUj+5jAwGtl/vC+E4oWA9j14xD7g=
=2Gqx
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

Le 24/11/2024 à 05:00, Fabian Grünbichler a écrit :

On Sat, Nov 23, 2024, at 5:50 PM, Chris Hofstaedtler wrote:

* Fabian Grünbichler <[email protected]> [241123 15:31]:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

D) follow the other teams and stop building Rust on i386.

I am not personally invested in i386 at all, but that is still not a call that I'd want to make as toolchain maintainer. If the release team prefers it over B) and over risking running into the miscompilation issues in practice, then I won't object.

FWIW, my (personal!) current preference would be B), followed by either documenting the issue and accepting it or D). Given the far-reaching implications of both B and D, I don't think this is a decision that either I or the Rust team can make alone.

+1 for B). I would be happy to do the same (enable ss2 extensions) for
llvm too.

S

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On 2024-11-24 11:00:20, Fabian Grünbichler wrote:

On Sat, Nov 23, 2024, at 5:50 PM, Chris Hofstaedtler wrote:

* Fabian Grünbichler <[email protected]> [241123 15:31]:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

D) follow the other teams and stop building Rust on i386.

I am not personally invested in i386 at all, but that is still not a call that I'd want to make as toolchain maintainer. If the release team prefers it over B) and over risking running into the miscompilation issues in practice, then I won't object.

FWIW, my (personal!) current preference would be B), followed by either documenting the issue and accepting it or D). Given the far-reaching implications of both B and D, I don't think this is a decision that either I or the Rust team can make alone.

I've been watching this thread from the sideline so far, but after
thinking some more, I don't understand why B) is simply not the chosen
path forward.

Are there viable/realistic platforms today that are i386 for real, and
don't support SSE2? In other words, if Debian as a whole does B) (not
only for rust), what is the practical impact on any non-toy hardware?

regards,
iustin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sun, 24 Nov 2024 at 13:25:59 +0100, Iustin Pop wrote:

Are there viable/realistic platforms today that are i386 for real, and
don't support SSE2? In other words, if Debian as a whole does B) (not
only for rust), what is the practical impact on any non-toy hardware?

SSE2 is well over 20 years old: in the Intel world, SSE2 was new in the
Pentium 4 (2000), and in the AMD world, SSE2 was new in the first
AMD64 CPUs (2003).

According to Wikipedia, the x86 CPUs without SSE2 since 2000 are:

- 32-bit AMD CPUs (Athlon XP and similar)
- VIA C3
- Transmeta Crusoe
- Intel Quark

We no longer release i386 kernels (since linux_6.11-1~exp1) and it has
already been announced that Debian 13 will not have i386 installation
media, so it is already the case that it is only possible to run trixie
on 32-bit x86 by upgrading from bookworm and keeping the bookworm kernel
(or installing a locally-built kernel).

If we raise the baseline to include SSE2, then we would lose the ability
to do that on Athlon XP, C3, Crusoe or Quark. I don't think that's a
practical problem in 2024: those are all designs from the early 2000s,
except for the Quark, which is a discontinued embedded processor that
we already cannot support in a reasonable way as a result of #738575.

According to Wikipedia, after raising the baseline it would still be
possible in principle to run i386 trixie using a bookworm or locally-built kernel on some of the later 32-bit Intel CPUs (Pentium 4, Pentium M,
Atom), or on Transmeta Efficeon or VIA C7.

i386 in trixie continues to be available as a multiarch foreign
architecture on x86_64 CPUs, or as an architecture for containers or
chroots running on an x86_64 kernel, but a baseline that includes SSE2
would not harm that use-case, because MMX, SSE and SSE2 are part of the
x86_64 baseline already.

My advice to anyone still running Debian on a 32-bit x86 machine would
be to look into acquiring a second-hand 64-bit laptop, many of which are already sufficiently old that they're most likely to be disposed of as
e-waste if unsold (so replacing an existing 32-bit machine would not be
a net increase in the amount of e-waste needing disposal). As an example,
here in the UK, eBay tells me I could receive a working Lenovo X200 next
week for �50, or a newer, faster and likely more power-efficient X280
for around �100.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Nov 24, 2024 at 01:25:59PM +0100, Iustin Pop wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc
C) disable all optimizations for Rust code on i386 (not really an option I think, just here for completeness sake)

D) follow the other teams and stop building Rust on i386.

I am not personally invested in i386 at all, but that is still not a call that I'd want to make as toolchain maintainer. If the release team prefers it over B) and over risking running into the miscompilation issues in practice, then I won't object.

FWIW, my (personal!) current preference would be B), followed by either documenting the issue and accepting it or D). Given the far-reaching implications of both B and D, I don't think this is a decision that either I or the Rust team can make alone.

I've been watching this thread from the sideline so far, but after
thinking some more, I don't understand why B) is simply not the chosen
path forward.

Nobody has made the choice or asked relevant people to make a choice, and relevant people haven't commented on this, to my knowledge (RT by their
own 2023 update are *not* relevant people wrt raising the baseline).
And among people who cannot make this choice but voice their opinion (or explicitly decline to have one) many are either conservative or think that
the project is, or should be, conservative. In other words, I feel like in
this specific case having many people on mailing lists hesitating about
this doesn't mean the project won't do that in the near future.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdDRIgtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh D58P/0tcJZ5Y0zHP8WcldMwAiBqu+Vax+/ahNSMwrcA/hzq7vQAwU0b7vyWGVToe oYWs/puGfsYR4Dmitkf45t5+e/3CR8T51f7ngQLJxuPdJldmQxgaGZAp8lazNTAv 913pFIMEoybu2jUfhNS95LIdgAyXFmsg8gEZVZVFyfXCoM4XxElIZ+1BsakcRs06 IckhjChLghINOeMviGZg5BxTlnv5rOtGLU2RueAii2grwFtmnFR/+iX5GOeb4lER OBLQwGomxsUYsREjbFQqq/mxYs7N2Y9iwEt/hQiU3MVeq5ebmj9eEm0Xhnx/p5Vm 3utFFTKLcz0XAdyos9JaF6D1EBMbM/ovkWwmOVhjMSaqYFcGhf3CSrAvJs/RgZA6 GKvJ0zGrp6+nc1u6ESgK7Nw2KGjea2/KGvAW3V0H4tMo9CknCs8iW09BFsoMj9JX eBdSaric3vW+eLYKl3bbIHPvY0n4mtJk3I3bKXoL7nC/gJe+1NN8ZivN2GVnfUTV SsJXJNa4QvCfM5kPY/GyjrNEzMnP2UoIcgflaqGClui7Z+e1GPG5v8wQq1ryqH9u JC17N8eD/vozkzpS53NYdvjbWAcHvRDlERnYCXByfSqJTG/E5RURKCIZu4ykknGY n833xUrjjyFsLXselpePJMaydJIqSU3yY5SYFHtmgmbpjkX4
=Wdiu
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le dimanche 24 novembre 2024, 08:27:31 CET Andrey Rakhmatullin a écrit :

On Sat, Nov 23, 2024 at 08:31:15PM +0000, Bastien Roucariès wrote:

B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc> > >

It will break I suppose imagemagick on i386 and scientific software testsuite

i386 means FPU so excess precision.

SSE is good and even better but excess precision is worked arround
thus FTBFS> >

Debian's i386 already has excess precision: https://wiki.debian.org/ArchitectureSpecificsMemo#i386

If you mean something else, could you be… more precise?

if SSE2 is enables gcc will not use i387 thus i386 will loss excess precision and have double like amd64

i387 => excess precision
SSE2 no excess precision

Which is a good thing normally.
Just remove the workarounds you mentioned.

I do not said it was a bad thing, I said just does we have time before release ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)