On 10/19/2026 1:29 PM, Pierrick Bouvier wrote: > 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.
Checking MAINTAINERS, I noticed you are working more on s390x side, and not ppc (I've been misled by @ibm.com). If I can help by pulling the series as part of tcg tests, let me know, and I'll send it on Thursday. Regards, Pierrick
