summary refs log tree commit diff stats
path: root/results/classifier/semantic-bugs/instruction/1901
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/semantic-bugs/instruction/1901')
-rw-r--r--results/classifier/semantic-bugs/instruction/190132
1 files changed, 0 insertions, 32 deletions
diff --git a/results/classifier/semantic-bugs/instruction/1901 b/results/classifier/semantic-bugs/instruction/1901
deleted file mode 100644
index 33ec55668..000000000
--- a/results/classifier/semantic-bugs/instruction/1901
+++ /dev/null
@@ -1,32 +0,0 @@
-instruction: 0.968
-graphic: 0.871
-device: 0.723
-semantic: 0.696
-other: 0.517
-network: 0.432
-socket: 0.404
-vnc: 0.392
-mistranslation: 0.243
-boot: 0.231
-assembly: 0.079
-KVM: 0.079
-
-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)