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
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
Attached Files:
-
signature.asc (0.50 KB)