add results

1 files changed, 37 insertions, 0 deletions

diff --git a/results/classifier/gemma3:27b/instruction/1915327 b/results/classifier/gemma3:27b/instruction/1915327
new file mode 100644
index 000000000..5651f2a1f
--- /dev/null
+++ b/results/classifier/gemma3:27b/instruction/1915327
@@ -0,0 +1,37 @@
+
+
+
+x86_64 cmpxchg behavior in qemu tcg does not match the real CPU
+
+QEMU version:
+1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into staging
+
+Consider the following little program:
+
+$ cat 1.c
+#include <stdio.h>
+int main() {
+  int mem = 0x12345678;
+  register long rax asm("rax") = 0x1234567812345678;
+  register int edi asm("edi") = 0x77777777;
+  asm("cmpxchg %[edi],%[mem]"
+      : [ mem ] "+m"(mem), [ rax ] "+r"(rax)
+      : [ edi ] "r"(edi));
+  long rax2 = rax;
+  printf("rax2 = %lx\n", rax2);
+}
+
+According to the Intel Manual, cmpxchg should not touch the accumulator in case the values are equal, which is indeed the case on the real CPU:
+
+$ gcc 1.c
+$ ./a.out 
+rax2 = 1234567812345678
+
+However, QEMU appears to zero extend EAX to RAX:
+
+$ qemu-x86_64 ./a.out 
+rax2 = 12345678
+
+This is also the case for lock cmpxchg.
+
+Found in BPF development context: https://lore<email address hidden>
\ No newline at end of file