1 files changed, 69 insertions, 0 deletions
diff --git a/results/classifier/118/performance/1590336 b/results/classifier/118/performance/1590336
new file mode 100644
index 00000000..fdec00db
--- /dev/null
+++ b/results/classifier/118/performance/1590336
@@ -0,0 +1,69 @@
+performance: 0.935
+graphic: 0.916
+architecture: 0.904
+assembly: 0.846
+device: 0.834
+arm: 0.833
+user-level: 0.778
+semantic: 0.752
+register: 0.750
+socket: 0.742
+files: 0.731
+ppc: 0.726
+PID: 0.648
+permissions: 0.645
+mistranslation: 0.642
+network: 0.640
+debug: 0.617
+TCG: 0.601
+vnc: 0.597
+kernel: 0.586
+peripherals: 0.585
+risc-v: 0.583
+hypervisor: 0.556
+virtual: 0.502
+VMM: 0.487
+boot: 0.460
+x86: 0.430
+i386: 0.394
+KVM: 0.385
+
+qemu-arm does not reject vrintz on non-v8 cpu
+
+Hello,
+
+It seems that qemu-arm does not reject some v8-only instructions as it should, but executes them "correctly".
+
+For instance, while compiling/running some of the GCC ARM instrinsics tests, we noticed that
+vrintz should be rejected on cortex-a9 for instance, while it is executed as if the instruction was supported.
+
+objdump says:
+   1074c:       f3fa05a0        vrintz.f32      d16, d16
+and qemu -d in_asm says:
+0x0001074c:  f3fa05a0      vabal.u<illegal width 64>    q8, d26, d16
+
+The problem is still present in qemu-2.6.0
+
+Should be fixed by http://patchwork.ozlabs.org/patch/633105/
+
+
+I confirm your patch does fix the problem.
+
+You may still want to fix the disassembler such that it dumps the right instruction, but that would be a separate fix.
+
+Thanks for your quick support.
+
+
+On 9 June 2016 at 20:14, Christophe Lyon <email address hidden> wrote:
+> You may still want to fix the disassembler such that it dumps the right
+> instruction, but that would be a separate fix.
+
+Unfortunately the disassembler is the pre-GPLv3 binutils one,
+so we can't just update it (and I'm not particularly inclined
+to independently re-implement all the 32-bit instruction set
+changes post that change).
+
+thanks
+-- PMM
+
+