From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EEB5015808B for ; Tue, 13 Feb 2024 19:53:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 227C0E2A2F; Tue, 13 Feb 2024 19:53:20 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C6FA9E2A21 for ; Tue, 13 Feb 2024 19:53:19 +0000 (UTC) References: User-agent: mu4e 1.10.8; emacs 30.0.50 From: Sam James To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [gentoo-dev-announce] x86 arch testing: please use -mfpmath=sse Date: Tue, 13 Feb 2024 19:37:03 +0000 Organization: Gentoo In-reply-to: Message-ID: <8734twp2dw.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: 8cb90339-0aff-4bd7-b8fa-4ec9032d0fb4 X-Archives-Hash: b8b3e10a70e382c36cadada641b29888 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Micha=C5=82 G=C3=B3rny writes: > [[PGP Signed Part:Undecided]] > Hello, > > TL;DR: when arch testing for x86, please use `-mfpmath=3Dsse` (this may > require raising `-march=3D` to `pentium4` or newer, or adding `-msse2`. > > > The x86 architecture historically supports two floating-precision > arithmetic modes: using the 387 coprocessor, and using the SSE > instruction set. The compilers default to using the former when > compiling for 32-bit x86, and the latter for amd64. > > The problem with 387 arithmetic is that it uses nonstandard 80-bit > registers (vs 64-bit doubles). While technically this means that it > achieves better precision, it often means that the same computations > yield different rounding results. As a result, test built against amd64 > fail with 387-based arithmetic. > > While technically these tests are broken in the first place for doing > exact matching on floating-point arithmetic results, getting everything > fixed is a major issue. These problems are quite unlikely to affect > real use cases. On top of that, many upstreams don't care about 32-bit > systems much, and bothering them with avoidable test failures reduces > our chances of having real problems solved. Yes. To be clear, this is NOT about us not caring about bugs without SSE or SSE2, but rather that right now, the spurious FP comparison failures are blocking stabilisation on x86 and are causing people to not want to look at x86 at all and keep calling for it to be destabled. I'm very happy to look into interesting problems, I just don't think it's a good use of anybody's time to be reporting these FP issues when it's taking time away from real problems on these platforms. We're better off with this by avoiding useless failures. We also did this for multilib x86 a while ago -- see ed189588a071f88186a3a9de25abfbd7582b9c69. > > Therefore, I would like to ask arch testers not to test with 387 > floating-point arithmetic anymore. We have already switched amd64 > multilib to use `-mfpmath=3Dsse` for 32-bit multilib, and we are planning > to provide x86 profiles with SSE2 baseline as well. > > Note that in order for `-mfpmath=3Dsse` to be fully effectively, the code > must be compiled with SSE2 support. This could be achieved by using `- > march=3Dpentium4` or higher, or adding `-msse2`. > > TIA. +1 thanks for doing this, sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZcvIq18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZA6pgD+KoDUbkKUmp6NsJMFnASH4eThyNsec0A481UF roQSZIMBAMS2rSkKYasg4vQuFTAyPQSssRXxX7NrlgfbNlRzoFoH =T8qM -----END PGP SIGNATURE----- --=-=-=--