On 10/19/26 4:32 PM, Pierrick Bouvier wrote:
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.
Yeah, I'm only noticing these running on an s390 host; would be good if
someone in PPC could chime in and confirm my suspicion, otherwise maybe
you could take this one via tcg tests since it's showing up now. I don't
think we ran this combination of tests prior to your meson rework? (I
couldn't reproduce these ppc errors, anyway.)
Thanks,
Eric
Regards,
Pierrick
