1 files changed, 49 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1901 b/results/classifier/118/graphic/1901
new file mode 100644
index 000000000..51c6b91d4
--- /dev/null
+++ b/results/classifier/118/graphic/1901
@@ -0,0 +1,49 @@
+graphic: 0.871
+architecture: 0.853
+performance: 0.843
+device: 0.723
+semantic: 0.696
+permissions: 0.608
+PID: 0.536
+ppc: 0.492
+virtual: 0.457
+network: 0.432
+files: 0.432
+peripherals: 0.422
+socket: 0.404
+vnc: 0.392
+register: 0.377
+hypervisor: 0.373
+TCG: 0.314
+debug: 0.287
+VMM: 0.269
+kernel: 0.267
+arm: 0.256
+risc-v: 0.245
+mistranslation: 0.243
+user-level: 0.241
+boot: 0.231
+assembly: 0.079
+KVM: 0.079
+x86: 0.068
+i386: 0.060
+
+qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction
+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](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c)