On 10/19/2026 11:56 AM, Eric Farman wrote: > There is an oddity that turns up with the float_convd and float_convs > tests, when running from different toolchains. As one example, the > expectation at the start of tests/tcg/ppc64/float_conv*.ref is: > > ### Rounding to nearest > from double: f64(nan:0x007ff4000000000000) > to single: f32(nan:0x7fe00000) (INVALID) > to int32: -2147483648 (INVALID) > to int64: -9223372036854775808 (INVALID) > to uint32: 0 (INVALID) > to uint64: -9223372036854775808 (INVALID) > > But, other hosts offer a different response, e.g., this debian guest > on my laptop: > > ### Rounding to nearest > from double: f64(nan:0x007ff4000000000000) > to single: f32(nan:0x7fe00000) (INVALID) > to int32: -2147483648 (INVALID) > to int64: -9223372036854775808 (INVALID) > to uint32: 0 (INVALID) > to uint64: 0 (INVALID) > > The explanation seems to be a behavior change when compiling to different > versions of power hardware. When building the arguments from the multiarch > directory, let's ensure these float tests offer a deterministic response > to these NaN tests by explicitly binding them to a CPU architecture. > > Chose power8 for no real reason. This behavior change appears between > power6 and power7, but other tests that rely on a specific architecture > today pick either power8 or power10. > > Signed-off-by: Eric Farman <[email protected]> > --- > tests/tcg/ppc64/float_convd.ref | 144 ++++++++++++++++---------------- > tests/tcg/ppc64/float_convs.ref | 80 +++++++++--------- > tests/tcg/ppc64/meson.build | 6 ++ > 3 files changed, 118 insertions(+), 112 deletions(-) >
Thanks for the update Eric, Reviewed-by: Pierrick Bouvier <[email protected]> I'll let you pull this as part of ppc64 subsystem. Also feel free to pull patch 1. Maybe let's just wait 2-3 days to see it Richard or Paolo have a specific comment, and then you can send that before the freeze date coming. Regards, Pierrick
