qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction

Host environment

  • Operating system: Gentoo GNU/Linux
  • OS/kernel version: Linux aion 6.4.9 #17 SMP PREEMPT Tue Aug 15 13:29:47 EDT 2023 ppc64le POWER9, altivec supported PowerNV C1P9S01 REV 1.02 GNU/Linux
  • Architecture: ppc64le
  • QEMU flavor: qemu-sparc64 / qemu-sparc32plus
  • QEMU version: qemu-sparc64 version 8.1.50 (v8.1.0-951-gb55e4b9c); also observed in 8.0.4 release
  • QEMU command line:
    qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16

Emulated/Virtualized environment

  • Operating system: N/A
  • OS/kernel version: N/A
  • Architecture: SPARC (v9 w/ VIS)

Description of problem

Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them).

The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications.

Steps to reproduce

  1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc:

    sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c
  2. Run it in qemu-sparc64:

    qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16
  3. Observe almost all tests fail.

    Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results.

Additional information

test_fmul8x16.c

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information