1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] x86 arch testing: please use -mfpmath=sse

    From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to All on Tue Feb 13 20:40:01 2024
    Hello,

    TL;DR: when arch testing for x86, please use `-mfpmath=sse` (this may
    require raising `-march=` 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.

    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=sse` for 32-bit multilib, and we are planning
    to provide x86 profiles with SSE2 baseline as well.

    Note that in order for `-mfpmath=sse` to be fully effectively, the code
    must be compiled with SSE2 support. This could be achieved by using `- march=pentium4` or higher, or adding `-msse2`.

    TIA.

    --
    Best regards,
    Michał Górny


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

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmXLw0YSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOkYEH/RtmQtIVDFIztYCEmRcMRoZLBAwfdcYY YoKIabLA6F3dqwwr247efQK4x19zeS4ynFgid6wQApeu4x6m05ByP7beyrJRh1Ra ln1JBMZiZCkHZVwTwOQJfOhLVmuVR0oXj09tSALrZQ62hV3UxbOXYYPPaqEpgXwD Z9To0Aq2xZV2kQ8cW+cgdXsQtW8duVasT56FWfpmkNlBWGk8zbldiJn2sNcy1h0g Cj89gfdnqR9u04EDnarExWBSUEn/tYZ4EMAEkW9rvcrw38U7Jkv0pTL9ChJvdfmh 3OBvAyS+UiC5s5YTzFK+7ujfDzlnXxOQfSdtfS51twCj7SclnsmHYAk=
    =EE0P
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to [email protected] on Tue Feb 13 21:00:02 2024
    Michał Górny <[email protected]> writes:

    [[PGP Signed Part:Undecided]]
    Hello,

    TL;DR: when arch testing for x86, please use `-mfpmath=sse` (this may
    require raising `-march=` 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=sse` for 32-bit multilib, and we are planning
    to provide x86 profiles with SSE2 baseline as well.

    Note that in order for `-mfpmath=sse` to be fully effectively, the code
    must be compiled with SSE2 support. This could be achieved by using `- march=pentium4` 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-----

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