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

[Michał Górny]

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

[Sam James]

Michał Górny <mgo...@gentoo.org> 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