diff options
Diffstat (limited to 'results/classifier/gemma3:12b/assembly')
152 files changed, 4845 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/assembly/1028 b/results/classifier/gemma3:12b/assembly/1028 new file mode 100644 index 000000000..4e70835cf --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1028 @@ -0,0 +1,35 @@ + +Assert fail for RISC-V RVV vmv.v.x for e64, vl == vl_max on RV32 guest +Description of problem: +assert message: +qemu/tcg/tcg-op-gvec.c:1714: tcg_gen_gvec_dup_i32: Assertion `vece <= MO_32' failed. + +For a e64 vmv.v.x, in the file trans_rvv.c.inc, function "trans_vmv_v_x", when s->vl_eq_vlmax is true, then "tcg_gen_gvec_dup_tl" (it's defined to tcg_gen_gvec_dup_i32 for RV32) is called. In "tcg_gen_gvec_dup_i32" the assert "tcg_debug_assert(vece <= MO_32) will be triggered, since vece == MO_64 for e64. +Steps to reproduce: +1.enable cfg.Zve64f + +2.Prepare a problem as set e64, vl == vl_max and use vmv.v.x, maybe as below +``` + li t0, -1, + vsetvli x0, t0, e64,m1,tu,mu + li t1, -1 + vmv.v.x v0, t1 +``` +Additional information: +Below is a possible solution if it's appropriate. +``` +#if TARGET_LONG_BITS == 32 + if (s->sew == 3) { + TCGv_i64 s1_i64 = tcg_temp_new_i64(); + tcg_gen_ext_tl_i64(s1_i64, s1); + tcg_gen_gvec_dup_i64(s->sew, vreg_ofs(s, a->rd), + MAXSZ(s), MAXSZ(s), s1_i64); + tcg_temp_free_i64(s1_i64); + } else { +#endif + tcg_gen_gvec_dup_tl(s->sew, vreg_ofs(s, a->rd), + MAXSZ(s), MAXSZ(s), s1); +#if TARGET_LONG_BITS == 32 + } +#endif +``` diff --git a/results/classifier/gemma3:12b/assembly/1093691 b/results/classifier/gemma3:12b/assembly/1093691 new file mode 100644 index 000000000..f684f30ce --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1093691 @@ -0,0 +1,33 @@ + +QEMU build fails on OpenBSD/mips64 + +Building QEMU 1.2.1 on OpenBSD/mips64 fails as follows although I believe QEMU was also broken with 1.1.x as well.. + +cc -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/slirp -I. -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1 -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/fpu -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg - +I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/mips -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmis +sing-prototypes -fno-strict-aliasing -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -DTIME_MAX=INT_MAX -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wf +ormat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/usr/obj/ports/qemu-1 +.2.1/qemu-1.2.1/target-i386 -DNEED_CPU_H -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/gli +b-2.0/include -I/usr/local/include -MMD -MP -MT tcg/tcg.o -MF tcg/tcg.d -O2 -pipe -c -o tcg/tcg.o /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c +In file included from /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c:50: +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_div_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: (Each undeclared identifier is reported only once +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: for each function it appears in.) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1231: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_rem_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1248: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1250: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_divu_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1267: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1269: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_remu_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1286: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1288: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext8s_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1526: error: 'TCG_TARGET_HAS_ext8s_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext16s_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1536: error: 'TCG_TARGET_HAS_ext16s_i64' undeclared (first use in this function) +... + +Attached is the full build log. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1096 b/results/classifier/gemma3:12b/assembly/1096 new file mode 100644 index 000000000..8b4f05a04 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1096 @@ -0,0 +1,2 @@ + +New warning with GCC 13 diff --git a/results/classifier/gemma3:12b/assembly/1104 b/results/classifier/gemma3:12b/assembly/1104 new file mode 100644 index 000000000..b538feabf --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1104 @@ -0,0 +1,2 @@ + +PAN support for AArch32 diff --git a/results/classifier/gemma3:12b/assembly/1119 b/results/classifier/gemma3:12b/assembly/1119 new file mode 100644 index 000000000..26cc7912e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1119 @@ -0,0 +1,16 @@ + +end_code set incorrectly +Description of problem: +https://github.com/qemu/qemu/blob/c99e34e537f13a431a80e3e414e5904e9dd0a116/linux-user/flatload.c#L811 + +This line says: + +``` +info->end_code = libinfo[0].start_code = libinfo[0].text_len; +``` + +but should be + +``` +info->end_code = libinfo[0].start_code + libinfo[0].text_len; +``` diff --git a/results/classifier/gemma3:12b/assembly/1154 b/results/classifier/gemma3:12b/assembly/1154 new file mode 100644 index 000000000..b7d41bd67 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1154 @@ -0,0 +1,2 @@ + +arm: M-profile loads and stores done via helpers should enforce alignment restrictions diff --git a/results/classifier/gemma3:12b/assembly/1233 b/results/classifier/gemma3:12b/assembly/1233 new file mode 100644 index 000000000..b65009d5b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1233 @@ -0,0 +1,2 @@ + +is there a roadmap about when riscv-v extension will be implemented?? diff --git a/results/classifier/gemma3:12b/assembly/1245543 b/results/classifier/gemma3:12b/assembly/1245543 new file mode 100644 index 000000000..fdd7f401b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1245543 @@ -0,0 +1,24 @@ + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1248 b/results/classifier/gemma3:12b/assembly/1248 new file mode 100644 index 000000000..7c53eeebd --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1248 @@ -0,0 +1,12 @@ + +s390x: glibc widestring algorithms broken +Description of problem: +Several wide-string functions from glibc are broken und qemu user emulation. +Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. + +Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. +Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. +Steps to reproduce: +1. Compile the test program above +2. Run the program +3. Output is `0`, should be `1`. diff --git a/results/classifier/gemma3:12b/assembly/1251 b/results/classifier/gemma3:12b/assembly/1251 new file mode 100644 index 000000000..2a1aa467d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1251 @@ -0,0 +1,16 @@ + +Octeon Instruction BBIT Bug +Steps to reproduce: +1. Compile 64bit binary for Octeon with Octeon instructions +`mips64-octeon-linux-gnu-gcc -o hello hello.c` +2. Run with `qemu-mips64` +`qemu-mips64 -cpu Octeon68XX hello` +3. Get the output below: +``` +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Additional information: +I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. + +[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/results/classifier/gemma3:12b/assembly/1267955 b/results/classifier/gemma3:12b/assembly/1267955 new file mode 100644 index 000000000..d916e7fe3 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1267955 @@ -0,0 +1,43 @@ + +[i386] Parity Flag Not Set On xor %eax,%eax + +Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid + +Steps To Reproduce + +$ cat > prog.hex << EOF + +7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 +02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 +00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00 +00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 +00 80 04 08 76 00 00 00 76 00 00 00 05 00 00 00 +00 10 00 00 + +31 c0 +9c + +b8 04 00 00 00 +bb 01 00 00 00 +89 e1 +ba 04 00 00 00 +cd 80 + +b8 01 00 00 00 +bb 00 00 00 00 +cd 80 + +EOF + +$ xxd -p -r prog.hex > prog +$ chmod 700 prog + +$ ./prog | hexdump -vC +00000000 46 02 00 00 |F...| +00000004 + +$ qemu-i386 ./prog | hexdump -vC +00000000 42 02 00 00 |B...| +00000004 + +On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1308381 b/results/classifier/gemma3:12b/assembly/1308381 new file mode 100644 index 000000000..54e2a538f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1308381 @@ -0,0 +1,15 @@ + +illegal instructions for AArch64 ARMv8 + +The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): +$aarch64-linux-gnu-gcc qemu.c -o test +$./test +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + +There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: +SQXTUN Bd, Hn +SQXTUN Hd, Sn +SQXTUN Sd, Dn. + +It seems that these instructions are not supported in QEMU. Is this a bug? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1319 b/results/classifier/gemma3:12b/assembly/1319 new file mode 100644 index 000000000..931c38a9a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1319 @@ -0,0 +1,14 @@ + +Build warnings when building qemu with 'disable-tcg' for ppc64-softmmu target +Description of problem: +Building recent upstream qemu (HEAD 2c8311241d) for 'ppc64-softmmu' target is failing due to following build warnings: + +<snip> + ../target/ppc/cpu_init.c:7018:13: error: 'ppc_restore_state_to_opc' defined but not used [-Werror=unused-function] + 7018 | static void ppc_restore_state_to_opc(CPUState *cs, +<snip> +Steps to reproduce: +1. $ git clone --recurse-submodules https://gitlab.com/qemu-project/qemu.git +2. ./configure --target-list=ppc64-softmmu --disable-tcg && make +Additional information: +Patch for this issue has been posted and reviewed at https://lore.kernel.org/all/20221116131743.658708-1-vaibhav@linux.ibm.com/ diff --git a/results/classifier/gemma3:12b/assembly/132 b/results/classifier/gemma3:12b/assembly/132 new file mode 100644 index 000000000..9d5fa8199 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/132 @@ -0,0 +1,2 @@ + +AVX instruction VMOVDQU implementation error for YMM registers diff --git a/results/classifier/gemma3:12b/assembly/1350 b/results/classifier/gemma3:12b/assembly/1350 new file mode 100644 index 000000000..cd8ba3eac --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1350 @@ -0,0 +1,90 @@ + +Regression in 7.2.0rc3: No snow by efi firmware in advent calendar 2020, door 15 anymore +Description of problem: +Advent calendar 2020, door 15 is expected to produce snow on the terminal while executing the provided efi firmware: + +> snow in micropython on slimbootloader by eldon +> ------------------------------------------- +> +> Today's advent is a custom efi firmware build of a new bootloader from intel called +> slimbootloader[1], a recent project by intel which has adapted micropython[2] as a +> utility for configuration and board testing. This build, however, will show snowfall on +> the console for a while. Eventually an exception drops the firmware into the micropython +> repl. +> +> [1] https://slimbootloader.github.io/supported-hardware/qemu.html +> [2] http://docs.micropython.org/en/latest/index.html + + +Snow does not fall anymore as it did with 7.1.0, it seems like execution is stopped/not started +Steps to reproduce: +- Build & Install from git source + ``` + /home/helge/qemu-project/qemu/configure --prefix=/home/helge/qemu-project/install \ + --target-list=x86_64-softmmu --disable-linux-user + make -j2 + make install + ``` + - Execute + ``` + PATH="/home/helge/qemu-project/install/bin" qemu-system-x86_64 \ + -m 256M -machine q35 -serial mon:stdio -vga none \ + -drive if=pflash,format=raw,file=snow.bin -boot a + ``` +Additional information: +Performing git bisect starting with tag v7.1.0 as good and tag v7.2.0-rc3 as bad reveals 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 as culprit: + ``` +$ git bisect start c4ffd91aba1c3d878e99a3e7ba8aad4826728ece 621da7789083b80d6f1ff1c0fb499334007b4f51 +binäre Suche: danach noch 965 Commits zum Testen übrig (ungefähr 10 Schritte) +[2ba341b3694cf3cff7b8a1df4cc765900d5c4f60] Merge tag 'kraxel-20221013-pull-request' of https://gitlab.com/kraxel/qemu into staging +$ git bisect good +binäre Suche: danach noch 482 Commits zum Testen übrig (ungefähr 9 Schritte) +[05c049f12b88370de7289bf39b14088c7d656caa] hw/isa/piix3: Remove extra ';' outside of functions +$ git bisect bad +binäre Suche: danach noch 228 Commits zum Testen übrig (ungefähr 8 Schritte) +[08a5d04606292b3cf6f5756bf2a095654a290626] Merge tag 'pull-tcg-20221026' of https://gitlab.com/rth7680/qemu into staging +$ git bisect bad +binäre Suche: danach noch 126 Commits zum Testen übrig (ungefähr 7 Schritte) +[168122419ed1c4087748e21131a523c6d9b632e1] target/arm: Change gen_goto_tb to work on displacements +$ git bisect bad +binäre Suche: danach noch 69 Commits zum Testen übrig (ungefähr 6 Schritte) +[2c65091fd9d387b8dca8115dbdd9c3c61f658a9e] Merge tag 'pull-ppc-20221017' of https://gitlab.com/danielhb/qemu into staging +$ git bisect good +binäre Suche: danach noch 34 Commits zum Testen übrig (ungefähr 5 Schritte) +[92ec056a6b2fc5d5a5593121c5d9475d2a2461d6] target/i386: reimplement 0x0f 0x60-0x6f, add AVX +$ git bisect bad +binäre Suche: danach noch 17 Commits zum Testen übrig (ungefähr 4 Schritte) +[8629e77be5f8106b3497cc197fbd57a12ae6333f] target/i386: Use probe_access_full for final stage2 translation +$ git bisect good +binäre Suche: danach noch 8 Commits zum Testen übrig (ungefähr 3 Schritte) +[20581aadec5e5a9d6836e4612b6f44a7cbda7d16] target/i386: validate VEX prefixes via the instructions' exception classes +$ git bisect good +binäre Suche: danach noch 4 Commits zum Testen übrig (ungefähr 2 Schritte) +[f05f9789f57d5394fc118fe31aa2a9f563311140] target/i386: extend helpers to support VEX.V 3- and 4- operand encodings +$ git bisect good +binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 1 Schritt) +[620f75566a5d81d7b82b3788b83d0b95c7d21dcd] target/i386: provide 3-operand versions of unary scalar helpers +$ git bisect good +binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt) +[b98f886c8f8661773047197d132efec97810b37a] target/i386: Introduce 256-bit vector helpers +$ git bisect good +92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 is the first bad commit +commit 92ec056a6b2fc5d5a5593121c5d9475d2a2461d6 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Tue Sep 20 05:42:45 2022 -0400 + + target/i386: reimplement 0x0f 0x60-0x6f, add AVX + + These are both MMX and SSE/AVX instructions, except for vmovdqu. In both + cases the inputs and output is in s->ptr{0,1,2}, so the only difference + between MMX, SSE, and AVX is which helper to call. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/decode-new.c.inc | 42 ++++++++ + target/i386/tcg/emit.c.inc | 202 +++++++++++++++++++++++++++++++++++++++ + target/i386/tcg/translate.c | 19 +++- + 3 files changed, 262 insertions(+), 1 deletion(-) + + ``` diff --git a/results/classifier/gemma3:12b/assembly/1350435 b/results/classifier/gemma3:12b/assembly/1350435 new file mode 100644 index 000000000..8cbd2e8ce --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1350435 @@ -0,0 +1,17 @@ + +tcg.c:1693: tcg fatal error + +this started happening after the launchpad buildd trusty deploy +https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439 + + +debconf-updatepo +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error +/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error + +this seems to be the patch needed +https://patches.linaro.org/32473/ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1357175 b/results/classifier/gemma3:12b/assembly/1357175 new file mode 100644 index 000000000..996293703 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1357175 @@ -0,0 +1,17 @@ + +qemu fails to build on powerpc64 + +Qemu fails to build on powerpc64, ELFv1 ABI, since the introduction of the ELFv2 ABI support. On FreeBSD/powerpc64 I see the following error building HEAD from today (8/14/2014): + +In file included from /home/chmeee/qemu-git/tcg/tcg.c:264: +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1737:3: error: #error "Unhandled abi" +In file included from /home/chmeee/qemu-git/tcg/tcg.c:264: +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c: In function 'tcg_target_qemu_prologue': +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: 'LINK_AREA_SIZE' undeclared (first use in this function) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: (Each undeclared identifier is reported only once +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: for each function it appears in.) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1778: error: 'LR_OFFSET' undeclared (first use in this function) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c: At top level: +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:2579: error: 'LINK_AREA_SIZE' undeclared here (not in a function) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:2605: error: 'LR_OFFSET' undeclared here (not in a function) +gmake[1]: *** [tcg/tcg.o] Error 1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1371 b/results/classifier/gemma3:12b/assembly/1371 new file mode 100644 index 000000000..5e034b309 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1371 @@ -0,0 +1,20 @@ + +x86 BLSMSK semantic bug +Description of problem: +The result of instruction BLSMSK is different with from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x65b2e276ad27c67"); + asm("mov rbx, 0x62f34955226b2b5d"); + asm("blsmsk eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - CF = 0 + - QEMU + - CF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:12b/assembly/1372 b/results/classifier/gemma3:12b/assembly/1372 new file mode 100644 index 000000000..ab4de144d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1372 @@ -0,0 +1,21 @@ + +x86 BEXTR semantic bug +Description of problem: +The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x17b3693f77fb6e9"); + asm("mov rbx, 0x8f635a775ad3b9b4"); + asm("mov rcx, 0xb717b75da9983018"); + asm("bextr eax, ebx, ecx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x5a + - QEMU + - RAX = 0x635a775a +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:12b/assembly/1402 b/results/classifier/gemma3:12b/assembly/1402 new file mode 100644 index 000000000..7e5f13aa2 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1402 @@ -0,0 +1,60 @@ + +cpu-exec.c fails to compile - code path is reachable +Description of problem: +Building qemu (tested with both gcc11 and gcc12) fails with: + +``` +[34/76] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +gcc -m64 -mcx16 -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm +-I../target/arm -I../dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader +-I/opt/ooce/include/pixman-1 +-I/data/omnios-build/omniosorg/qemu/libtasn1-4.19.0/out/include +-I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include +-fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g +-iquote . -iquote /data/omnios-build/omniosorg/qemu +-iquote /data/omnios-build/omniosorg/qemu/include +-iquote /data/omnios-build/omniosorg/qemu/tcg/i386 +-pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE +-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes +-fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition +-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers +-Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined +-Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value +-Wno-psabi -fstack-protector-strong -m64 -gdwarf-2 -gstrict-dwarf +-fno-omit-frame-pointer -fno-aggressive-loop-optimizations -DNEED_CPU_H +'-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' +'-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ +libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +-MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o.d +-o libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +-c ../accel/tcg/cpu-exec.c +In file included from ../accel/tcg/cpu-exec.c:20: +In function 'tb_pc', + inlined from 'cpu_tb_exec' at ../accel/tcg/cpu-exec.c:465:13: +/data/omnios-build/omniosorg/qemu/include/qemu/osdep.h:184:35: error: call to 'qemu_build_not_reached_always' declared with attribute error: code path is reachable + 184 | #define qemu_build_not_reached() qemu_build_not_reached_always() + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/data/omnios-build/omniosorg/qemu/include/exec/exec-all.h:608:5: note: in expansion of macro 'qemu_build_not_reached' + 608 | qemu_build_not_reached(); + | ^~~~~~~~~~~~~~~~~~~~~~ +``` +Additional information: +It appears that the compiler is not smart enough to realise that `TARGET_TB_PCREL` is false in the branch there or is not able to infer that from the `assert()`. + +Adding an explicit check as a workaround allows compilation to continue. + +```diff +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -459,7 +459,7 @@ cpu_tb_exec(CPUState *cpu, TranslationBlock *itb, int *tb_exit) + + if (cc->tcg_ops->synchronize_from_tb) { + cc->tcg_ops->synchronize_from_tb(cpu, last_tb); +- } else { ++ } else if (!TARGET_TB_PCREL) { + assert(!TARGET_TB_PCREL); + assert(cc->set_pc); + cc->set_pc(cpu, tb_pc(last_tb)); +``` diff --git a/results/classifier/gemma3:12b/assembly/1414293 b/results/classifier/gemma3:12b/assembly/1414293 new file mode 100644 index 000000000..9b349e2b2 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1414293 @@ -0,0 +1,6 @@ + +target-lm32/translate.c:336: bad ? : operator + +[qemu/target-lm32/translate.c:336]: (style) Same expression in both branches of ternary operator. + + int rY = (dc->format == OP_FMT_RR) ? dc->r0 : dc->r0; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1422 b/results/classifier/gemma3:12b/assembly/1422 new file mode 100644 index 000000000..7275f07bb --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1422 @@ -0,0 +1,16 @@ + +/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q' +Description of problem: +Qemu 7.2.0 doesn't build on powerpc64le. +Steps to reproduce: +Build qemu. +Additional information: +``` +FAILED: libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o +cc -m64 -mlittle-endian -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/pixman-1 -I/usr/local/include -I/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/include -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -MF libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o.d -o libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -c ../tcg/tcg.c +In file included from ../tcg/tcg.c:432: +/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q' + asm("mr %%r6, %1\n\t" + ^ +1 error generated. +``` diff --git a/results/classifier/gemma3:12b/assembly/1435 b/results/classifier/gemma3:12b/assembly/1435 new file mode 100644 index 000000000..e6f16b5dc --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1435 @@ -0,0 +1,17 @@ + +Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. +Description of problem: +`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. + +I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). + +One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. +Steps to reproduce: +(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). + +1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. +2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. +3. Rinse and repeat. +4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/1437811 b/results/classifier/gemma3:12b/assembly/1437811 new file mode 100644 index 000000000..6433f130d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1437811 @@ -0,0 +1,8 @@ + +target-tricore/op_helper.c:2576: bad if statement + +[qemu/target-tricore/op_helper.c:2576]: (style) Expression '(X & 0x400000) == 0x1' is always false. + + if ((env->PCXI & MASK_PCXI_UL) == 1) { + /* CTYP trap */ + } \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1452 b/results/classifier/gemma3:12b/assembly/1452 new file mode 100644 index 000000000..c8ff664b9 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1452 @@ -0,0 +1,2 @@ + +Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/gemma3:12b/assembly/1469342 b/results/classifier/gemma3:12b/assembly/1469342 new file mode 100644 index 000000000..f16a1b935 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1469342 @@ -0,0 +1,4 @@ + +qemu-i386 pentium3/athlon incorrect instruction set + +Running a binary containing a movsd instruction (SSE2) in 32-bit qemu-i386 -cpu pentium3 from 20150609 results in flawless execution whereas it should crash with SIGILL as P3 only had SSE. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1486911 b/results/classifier/gemma3:12b/assembly/1486911 new file mode 100644 index 000000000..aa7297e4d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1486911 @@ -0,0 +1,47 @@ + +Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian)) + +When compiling from source occurs to me incomprehensible error. +Operation ./configure runs without problems, but among the logs make see this: + CP i386-softmmu / hw / i386 / acpi-dsdt.hex + CP i386-softmmu / hw / i386 / q35-acpi-dsdt.hex + CP i386-softmmu / hw / i386 / ssdt-tpm.hex + CC i386-softmmu / target-i386 / translate.o + CC m68k-softmmu / tcg / tcg-op.o + CC m68k-softmmu / tcg / optimize.o +In file included from /home/pi/Zagruzki/qemu-2.3.1/include/qapi/error.h:16:0, + from /home/pi/Zagruzki/qemu-2.3.1/include/qemu/option.h:31, + from /home/pi/Zagruzki/qemu-2.3.1/include/qemu-common.h:44, + from /home/pi/Zagruzki/qemu-2.3.1/tcg/optimize.c:31: +/home/pi/Zagruzki/qemu-2.3.1/qapi-types.h:196:8: error: unknown type name '$ uint64_t' +/home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «tcg / optimize.o» +make [1]: *** [tcg / optimize.o] Error 1 +Makefile: 173: error is the recipe for the purpose of «subdir-m68k-softmmu» +make: *** [subdir-m68k-softmmu] Error 2 +make: *** Waiting for jobs ... + +When you try to create a package using checkinstall is such error: +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c: In function 'helper_msa_copy_s_df': +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: error: unrecognizable insn: +(insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0) + (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167) + (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr [ws_9 (D)]. wr.b S1 A8]))) /home/pi/Zagruzki/qemu-2.3.1/target- mips / msa_helper.c: 1253 -1 + (nil)) +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: internal compiler error: in extract_insn, at recog.c: 2109 +Please submit a full bug report, +with preprocessed source if appropriate. +See <file: ///usr/share/doc/gcc-4.6/README.Bugs> for instructions. +Preprocessed source stored into /tmp/cc1quRqL.out file, please attach this to your bugreport. +/home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «target-mips / msa_helper.o» +make [1]: *** [target-mips / msa_helper.o] Error 1 +Makefile: 173: error is the recipe for the purpose of «subdir-mips64-softmmu» +make: *** [subdir-mips64-softmmu] Error 2 + +**** Installation unsuccessful. It cancels the creation of the package. + +Cleared ... OK + +Good luck. + +Log make, checkinstall from the terminal http://rghost.ru/7SK6y4bs6 +cc1quRqL.out applications \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1511 b/results/classifier/gemma3:12b/assembly/1511 new file mode 100644 index 000000000..91d8d49b7 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1511 @@ -0,0 +1,2 @@ + +Please a CPU model for ABI version for x86_64 i386 according to x86-64 psABI diff --git a/results/classifier/gemma3:12b/assembly/1514 b/results/classifier/gemma3:12b/assembly/1514 new file mode 100644 index 000000000..3864312b6 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1514 @@ -0,0 +1,2 @@ + +Cpu flags for ARM is surprising diff --git a/results/classifier/gemma3:12b/assembly/1533141 b/results/classifier/gemma3:12b/assembly/1533141 new file mode 100644 index 000000000..42761df9a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1533141 @@ -0,0 +1,16 @@ + +qemu/disas/libvixl/vixl/invalset.h: 2 * sanity check after use ? + +1. + +[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check. + + while (!IsValid(elements[low]) && (low < high)) ++low; + +2. + +[qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check. + + while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle; + +Also, binary search is a standard C library routine. Suggest use. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1536 b/results/classifier/gemma3:12b/assembly/1536 new file mode 100644 index 000000000..6dffdf5a0 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1536 @@ -0,0 +1,17 @@ + +Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) +Description of problem: +Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). +Steps to reproduce: +1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. +2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. +3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. +4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. + +The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: +1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. +2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. +3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: + - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/gemma3:12b/assembly/1550503 b/results/classifier/gemma3:12b/assembly/1550503 new file mode 100644 index 000000000..ea65b42c0 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1550503 @@ -0,0 +1,14 @@ + +target-arm/helper.c:5493: bad test ? + +[qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != 0xf80f0000' is always true. + +Source code is + + (env->uncached_cpsr & CPSR_M) != CPSR_USER && + +but + +./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU) + +./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1581 b/results/classifier/gemma3:12b/assembly/1581 new file mode 100644 index 000000000..2564652e9 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1581 @@ -0,0 +1,15 @@ + +QEMU TCG crashes when running on windows +Description of problem: +QEMU crashes immediately after startup and shows an assertion failure： + +ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == 32) + +Bail out! ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == + 32) +Steps to reproduce: +NA +Additional information: +1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux. +2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur. +3. This problem does not exist in the QEMU version 7.2. diff --git a/results/classifier/gemma3:12b/assembly/1590336 b/results/classifier/gemma3:12b/assembly/1590336 new file mode 100644 index 000000000..e2c646d0f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1590336 @@ -0,0 +1,16 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1591611 b/results/classifier/gemma3:12b/assembly/1591611 new file mode 100644 index 000000000..0838cb55c --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1591611 @@ -0,0 +1,24 @@ + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1592 b/results/classifier/gemma3:12b/assembly/1592 new file mode 100644 index 000000000..528082cec --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1592 @@ -0,0 +1,17 @@ + +QEMU v8.0.0 crashes when running in TCG mode on windows OS +Description of problem: +This bug is a follow-up to issue #1581. +After the patch 7d9e1ee424b06a43708be02474e6714962cfee92 is merged, QEMU segfaults at startup. +And the location where the segfault occurs here(from coredump): +``` +atomic_common.c.inc:60 +CMPXCHG_HELPER(cmpxchgo_le, Int128) +``` +Steps to reproduce: +NA +Additional information: +1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux. +2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur. +3. This problem does not exist in the QEMU version 7.2. +4. What is even more confusing is that if you use gdb to load qemu and run it, this issue cannot be reproduced. diff --git a/results/classifier/gemma3:12b/assembly/1612 b/results/classifier/gemma3:12b/assembly/1612 new file mode 100644 index 000000000..896b40670 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1612 @@ -0,0 +1,52 @@ + +SVE first-faulting gather loads return incorrect data +Description of problem: +The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. +Steps to reproduce: +1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`. + +asmtest.s +``` + .type asmtest, @function + .balign 16 + .global asmtest +asmtest: + setffr + ptrue p0.d + index z1.d, #0, #1 + ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] + rdffr p1.b + st1d {z1.d}, p0, [x1] + str p1, [x2] + ret +``` + +This harness for convenience intialises some data and checks the element at index 1, which should be 1. + +test.c +``` +#include <arm_sve.h> +#include <stdio.h> + +void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); + +int main() { + const int64_t data[] = {42, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, + 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, + 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}; + svint64_t loaded; + svbool_t ffr; + + asmtest(data, &loaded, &ffr); + + // Check value of element at index 1 + svuint64_t lanes = svindex_u64(0, 1); + svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); + printf("%ld\n", svaddv_s64(lane, loaded)); +} +``` + +2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` +3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. +Additional information: +The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/gemma3:12b/assembly/1619 b/results/classifier/gemma3:12b/assembly/1619 new file mode 100644 index 000000000..c6ec1ef4c --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1619 @@ -0,0 +1,2 @@ + +Emulate x86_64 on ARM machine diff --git a/results/classifier/gemma3:12b/assembly/1620 b/results/classifier/gemma3:12b/assembly/1620 new file mode 100644 index 000000000..f603c8ec5 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1620 @@ -0,0 +1,95 @@ + +SME FMOPA outer product instruction gives incorrect result +Description of problem: +The SME outer product instructions operate on tiles of elements. In the +below example we are performing an outer product of a vector of 1.0 +by itself. This naturally should produce a matrix filled with 1.0 +values, however if we read the values of the tile and printf them we +instead observe 0.0 values. + +Without digging into the underlying QEMU code this appears to be a bug +in how elements are set based on the tile number, since the same code +using za0.s rather than za1.s correctly reports all 1.0 values as output +as expected. + +main.c +``` +#include <stdio.h> + +void foo(float *dst); + +int main() { + float dst[16]; + foo(dst); + + // This should print: + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%lf ", (double)dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.s, vl4 + fmov z0.s, #1.0 + + // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. + // Note that we are using tile 1 here (za1.s) rather than tile 0. + zero {za} + fmopa za1.s, p0/m, p0/m, z0.s, z0.s + + // Read the first 4x4 sub-matrix of elements from tile 1: + // Note that za1h should be interchangable here. + mov w12, #0 + mova z0.s, p0/m, za1v.s[w12, #0] + mova z1.s, p0/m, za1v.s[w12, #1] + mova z2.s, p0/m, za1v.s[w12, #2] + mova z3.s, p0/m, za1v.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static +$ ~/qemu/build/qemu-aarch64 ./a.out +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +``` diff --git a/results/classifier/gemma3:12b/assembly/1631625 b/results/classifier/gemma3:12b/assembly/1631625 new file mode 100644 index 000000000..9987cd848 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1631625 @@ -0,0 +1,16 @@ + +target-mips/dsp_helper.c: two possible bad shifts + +target-mips/dsp_helper.c:3480:1: error: V629 Consider inspecting the '0x01 << (size + 1)' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. + +Source code is + + temp = temp & ((0x01 << (size + 1)) - 1); + +If size >= 32, then better code might be + + temp = temp & ((0x01UL << (size + 1)) - 1); + +target-mips/dsp_helper.c:3509:1: error: V629 Consider inspecting the '0x01 << (size + 1)' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. + +Duplicate \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/164 b/results/classifier/gemma3:12b/assembly/164 new file mode 100644 index 000000000..b4f2b5cfb --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/164 @@ -0,0 +1,2 @@ + +qemu x86 TCG doesn't support AVX insns diff --git a/results/classifier/gemma3:12b/assembly/1641637 b/results/classifier/gemma3:12b/assembly/1641637 new file mode 100644 index 000000000..d9d143a24 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1641637 @@ -0,0 +1,714 @@ + +incorrect illegal SSE3 instructions reporting on x86_64 + +Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: + +pabsb %mm0, %mm1 +pabsb %xmm0, %xmm1 +pabsd %mm0, %mm1 +pabsd %xmm0, %xmm1 +pabsw %mm0, %mm1 +pabsw %xmm0, %xmm1 +phaddd %mm0, %mm1 +phaddd %xmm0, %xmm1 +phaddsw %mm0, %mm1 +phaddsw %xmm0, %xmm1 +phaddw %mm0, %mm1 +phaddw %xmm0, %xmm1 +phsubd %mm0, %mm1 +phsubd %xmm0, %xmm1 +phsubsw %mm0, %mm1 +phsubsw %xmm0, %xmm1 +phsubw %mm0, %mm1 +phsubw %xmm0, %xmm1 +pmaddubsw %mm0, %mm1 +pmaddubsw %xmm0, %xmm1 +pmulhrsw %mm0, %mm1 +pmulhrsw %xmm0, %xmm1 +psignb %mm0, %mm1 +psignb %xmm0, %xmm1 +psignd %mm0, %mm1 +psignd %xmm0, %xmm1 +psignw %mm0, %mm1 +psignw %xmm0, %xmm1 + +The following is the proof of code + +/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 1.c **********/ + + +/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 2.c **********/ + + +/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 3.c **********/ + + +/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 4.c **********/ + + +/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 5.c **********/ + + +/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 6.c **********/ + + +/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 7.c **********/ + + +/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 8.c **********/ + + +/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 9.c **********/ + + +/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 10.c **********/ + + +/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 11.c **********/ + + +/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 12.c **********/ + + +/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 13.c **********/ + + +/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 14.c **********/ + + +/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 15.c **********/ + + +/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 16.c **********/ + + +/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 17.c **********/ + + +/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 18.c **********/ + + +/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 19.c **********/ + + +/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 20.c **********/ + + +/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 21.c **********/ + + +/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 22.c **********/ + + +/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 23.c **********/ + + +/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 24.c **********/ + + +/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 25.c **********/ + + +/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 26.c **********/ + + +/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 27.c **********/ + + +/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 28.c **********/ + +For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, + +$ gcc 28.c -o 28 +$ qemu-x86_64 ./28 +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +$ ./28 +00000000000000000000000000000000 + +Some information about the system: + +$ qemu-x86_64 --version +qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +$ uname -a +Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +$ gcc --version +gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 +Copyright (C) 2013 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1642 b/results/classifier/gemma3:12b/assembly/1642 new file mode 100644 index 000000000..08a23b62f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1642 @@ -0,0 +1,23 @@ + +Qemu aarch64 tcg crashes when emulating an STXP instruction but only on a Windows host +Description of problem: +Qemu segfaults when trying to emulate an STXP instruction, but only when running natively on a windows host (msys2 build). This is not the same as https://gitlab.com/qemu-project/qemu/-/issues/1581. + +I've managed to git-bisect it to this change: https://github.com/qemu/qemu/commit/546789c7df8866c55cae8d3195e8e58328a35d51 +Sadly i cannot investigate it further and contribute a fix, but it seems like a problem with one of the I128 arguments to `helper_atomic_cmpxchgo_le ` + +UPD: Issue is also in master (as of `caa9cbd566877b34e9abcc04d936116fc5e0ab28`) +Steps to reproduce: +N/A +Additional information: +``` +Thread 9 received signal SIGSEGV, Segmentation fault. +0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, addr=18446684150325987376, oldv=46236672343829145701101521005152, newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +60 CMPXCHG_HELPER(cmpxchgo_le, Int128) +(gdb) bt +#0 0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, + addr=18446684150325987376, oldv=46236672343829145701101521005152, + newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +#1 0x00000247a124f73d in ?? () + +``` diff --git a/results/classifier/gemma3:12b/assembly/1661 b/results/classifier/gemma3:12b/assembly/1661 new file mode 100644 index 000000000..e44693eb1 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1661 @@ -0,0 +1,12 @@ + +x86 cpu support request: LX Geode +Description of problem: +The Geode LX family of CPUs were used in early generations of the One Laptop Per Child (OLPC) systems (XO 1.0). + +They are _basically_ i686-compatible but they lack the 'long-nop' (0x0f 0x1f) instruction available on many other i686-class devices. + +Since i686 is a reasonably common baseline for toolchains and the software that is distributed using those toolchains, it would be convenient to be able to use QEMU to test boundary compatibility cases for this CPU. +Steps to reproduce: +N/A - feature does not currently exist +Additional information: +I'm not adding additional context here at the moment, but please let me know what else would be helpful to know (and/or if I'm off-track with this feature request for any reason). Thank you! diff --git a/results/classifier/gemma3:12b/assembly/1667 b/results/classifier/gemma3:12b/assembly/1667 new file mode 100644 index 000000000..049e705c4 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1667 @@ -0,0 +1,2 @@ + +Tricore: missing a few TC1.6.2 instruction set diff --git a/results/classifier/gemma3:12b/assembly/1673 b/results/classifier/gemma3:12b/assembly/1673 new file mode 100644 index 000000000..26a240d18 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1673 @@ -0,0 +1,50 @@ + +compilation of 8.0.0 FAILED: target/hexagon/idef-generated-emitter.indented.c on ubuntu 18.04 +Description of problem: +Cannot compile on ubuntu 18.04. +Steps to reproduce: +1. get 8.0.0 tarball or git clone/submodule... on a ubuntu 18.04 system (with a few more recent tools in ~/opt, such as python 3.9) +2. ./configure --prefix=$HOME/opt && make +3. It finishes with this strange error: FAILED: target/hexagon/idef-generated-emitter.indented.c +``` +... +[850/10154] Compiling C object target/hexagon/idef-parser.p/meson-generated_idef-parser.yy.c.o +[851/10154] Compiling C object target/hexagon/idef-parser.p/meson-generated_idef-parser.tab.c.o +[852/10154] Compiling C object target/hexagon/idef-parser.p/_home_pbourguignon_opt_src_qemu-8.0.0_target_hexagon_idef-parser_parser-helpers.c.o +[853/10154] Linking target target/hexagon/idef-parser +[854/10154] Generating target/hexagon/idef-generated-tcg with a custom command +[855/10154] Generating target/hexagon/indent with a custom command +FAILED: target/hexagon/idef-generated-emitter.indented.c +/home/pbourguignon/bin/indent -linux target/hexagon/idef-generated-emitter.c -o target/hexagon/idef-generated-emitter.indented.c +Indenting region... +Indenting region... done +Directory `/home/pbourguignon/opt/src/qemu-8.0.0/build/-linux target/hexagon/idef-generated-emitter.c -o target/hexagon/' does not exist; create? (y or n) Error reading from stdin +ninja: build stopped: subcommand failed. +Makefile:165: recipe for target 'run-ninja' failed +make[1]: *** [run-ninja] Error 1 +make[1]: Leaving directory '/home/pbourguignon/opt/src/qemu-8.0.0/build' +GNUmakefile:10: recipe for target 'all' failed +make: *** [all] Error 2 +``` +Additional information: +https://dpaste.org/Hr9Zq +``` +~/opt/src/qemu-git +16:15[pbourguignon@frprld7818008 :0.0 qemu-git ]$ ls ~/opt/bin +./ ecl-config* pydoc3@ run-avr* run-microblaze* +../ emacs@ pydoc3.9* run-bfin* run-mips* +2to3@ emacs-27.2* python@ run-bpf* run-mn10300* +2to3-3.9* emacsclient* python3@ run-cr16* run-moxie* +bundle* erb* python3-config@ run-cris* run-msp430* +bundler* etags* python3.9* run-d10v* run-or1k* +ccl* gcore* python3.9-config* run-erc32* run-ppc* +ccmake* gdb* racc* run-frv* run-pru* +cmake* gdb-add-index* rake* run-ft32* run-riscv* +cpack* gdbserver* rbs* run-h8300* run-rl78* +ctags* gem* rdbg* run-iq2000* run-rx* +ctest* idle3@ rdoc* run-lm32* run-sh* +curl* idle3.9* ri* run-m32c* run-v850* +curl-config* irb* ruby* run-m32r* sbcl* +ebrowse* pip3* run-aarch64* run-m68hc11* sis* +ecl* pip3.9* run-arm* run-mcore* typeprof* +``` diff --git a/results/classifier/gemma3:12b/assembly/1698 b/results/classifier/gemma3:12b/assembly/1698 new file mode 100644 index 000000000..5c25980a2 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1698 @@ -0,0 +1,2 @@ + +Global-buffer-overflow in QEMU TirCore TCG diff --git a/results/classifier/gemma3:12b/assembly/1699 b/results/classifier/gemma3:12b/assembly/1699 new file mode 100644 index 000000000..3da65dc33 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1699 @@ -0,0 +1,2 @@ + +Tricore: Call instruction wrong diff --git a/results/classifier/gemma3:12b/assembly/1711828 b/results/classifier/gemma3:12b/assembly/1711828 new file mode 100644 index 000000000..1cda39273 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1711828 @@ -0,0 +1,4 @@ + +lock mov non generated #UD + +qemu 2.8.1 debian 9.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1714 b/results/classifier/gemma3:12b/assembly/1714 new file mode 100644 index 000000000..760880b47 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1714 @@ -0,0 +1,28 @@ + +QEMU crashes on ARMv7 since at least commit 493c9b19 +Description of problem: +I'm trying to build QEMU for Android, Arm64 versions work well, but **Armv7** builds began to crash nearly since this series of commits (QEMU 7.2.50), related to 'TCG_TARGET_HAS_direct_jump' removal by @rth7680. +More precisely, this commit still works: + +https://gitlab.com/qemu-project/qemu/-/commit/82df11e78d0baef7ffb7e7933c6fb830ffed087c + +and this one crashes: + +https://gitlab.com/qemu-project/qemu/-/commit/493c9b19a7fb7f387c4fcf57d3836504d5242bf5 + +(I tracked commits of 'tcg' subfolder and didn't bisect finer, but it's possible if needed). + +Both qemu-system-x86_64 and qemu-system-i386 emulators crash. + +**The crash is related to translation buffer size** : if I don't specify "-accel tcg,thread=single **,tb-size=256** ", the machine works. + +The problem is that I can not run debugger on a phone, and crash dump does not show any useful information, just "segfault" reason ("Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe19b8000"). + +Even more, the Linux starts and runs, but it crashes only when I'm trying to run the GIMP, between splash screen and main interface appearance. + +I know that 1) Android is not officially supported and 2) 32-bit hosts were considered deprecated recently, but maybe it's possible to do something with these crashes? + +Recent master (https://gitlab.com/qemu-project/qemu/-/commit/5692a39f329413a00020a61fff95aff6b9884a73) doesn't work as well. +All 8.0.x Arm64 builds are runnable. + +Thanks in advance. diff --git a/results/classifier/gemma3:12b/assembly/1721275 b/results/classifier/gemma3:12b/assembly/1721275 new file mode 100644 index 000000000..8d3f5d692 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1721275 @@ -0,0 +1,27 @@ + +Support more ARM CPUs + +Hi, + +This is an enhancement request, rather than a bug report. + +After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters. + +I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for. + +I'd like to have: +cortex-m0 +cortex-m4 +cortex-m7 +cortex-m23 +cortex-m33 + +cortex-a35 +cortex-a53 +cortex-a57 + +Is it possible? +Is it the right place to ask? +Should I file separate requests for each? + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1725267 b/results/classifier/gemma3:12b/assembly/1725267 new file mode 100644 index 000000000..72719bd2f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1725267 @@ -0,0 +1,32 @@ + +armeb regression since qemu version 2.8 + +Hi, + +I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1. + +I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe. + +# with 2.7: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +$ echo $? +0 +# with 2.8, 2.10.1: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) +$ echo $? +134 + +The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c + +Running with -d in_asm shows a difference early in the startup code: +IN: _dl_sysdep_start +[...] +0x40a17790: 908ff103 addls pc, pc, r3, lsl #2 + +and then the next address is not the same with qemu 2.7 and 2.10.1 + +I hope you have enough data/information to reproduce and confirm/fix the problem. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1737 b/results/classifier/gemma3:12b/assembly/1737 new file mode 100644 index 000000000..dfcc94757 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1737 @@ -0,0 +1,50 @@ + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/1750 b/results/classifier/gemma3:12b/assembly/1750 new file mode 100644 index 000000000..c2ed8d05b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1750 @@ -0,0 +1,2 @@ + +target/ppc/translate.c - ppc_fixup_cpu and VSX - is still necessary? diff --git a/results/classifier/gemma3:12b/assembly/1751494 b/results/classifier/gemma3:12b/assembly/1751494 new file mode 100644 index 000000000..aaac9ad89 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1751494 @@ -0,0 +1,17 @@ + +tcg-target.inc.c:3495:no such instruction: `xgetbv' + +While building QEMU on Mac OS 10.6.8 I saw this error message: +tag-target.inc.c:3495:no such instruction: `xgetbv' +In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: +asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); + +https://github.com/asmjit/asmjit/issues/78 +According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. + +Host info: +Mac OS 10.6.8 +GCC 5.2.0 + +Additional information: +This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1755479 b/results/classifier/gemma3:12b/assembly/1755479 new file mode 100644 index 000000000..78ee0848a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1755479 @@ -0,0 +1,26 @@ + +Cortex M:qemu abort with optimized code and icount + +A basic program runs fine if compiled with flag -O0 with gcc, but triggers a qemu abort when compiled with -O1 and run with icount: +"qemu: fatal: IO on conditional branch instruction" + +I also noticed the problem on C source like this with -O0: +"int foo = *bar; bar++;" : OK +"int foo = *bar++;" : FAIL (!!!) + +Optimized binary attached to this ticket. + +command line: +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -serial file:$(tty) -icount 4 -cpu cortex-m4 +(working fine without icount) + +version: +QEMU emulator version 2.11.50 (v2.11.0-2146-gd9bbfea-dirty) + +Compilation options: +./configure --target-list=arm-softmmu --disable-slirp --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native + +I have also tested previous versions: +- stock qemu-system-arm 2.5.0 from ubuntu 16.04: OK +- git version: QEMU emulator version 2.10.0 (v2.10.2-dirty): OK +- git version: QEMU emulator version 2.10.90 (v2.11.0-rc0-dirty): FAIL \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1781281 b/results/classifier/gemma3:12b/assembly/1781281 new file mode 100644 index 000000000..681dd761e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1781281 @@ -0,0 +1,29 @@ + +qemu-ppc64le uncaught target signal 4 (Illegal instruction) + +qemu-ppc64le version 2.12.0 +host machine: x86_64 Arch Linux + +I'm currently working on VSX support in libVPX, I'm using qemu to test, on line 723 of vpx_dsp/ppc/loopfilter_vsx.c, when I change the vec_sub to vec_subs I get: + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +Thread 1 "qemu-ppc64le" received signal SIGILL, Illegal instruction. +0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +#1 0x000055555567ee68 in ?? () +#2 0x000055555567fd18 in ?? () +#3 0x00005555556805ef in process_pending_signals () +#4 0x0000555555661e69 in cpu_loop () +#5 0x000055555561fd72 in main () + +This can be reproduced by downloading this patch (patchset 1): + +https://chromium-review.googlesource.com/c/webm/libvpx/+/1134034 + +and running + +qemu-ppc64le -L /home/ltrudeau/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot/ ./test_libvpx --gtest_also_run_disabled_tests "--gtest_filter=VSX/*Loop*/*" + +I don't observe any issues when running the code on a POWER9 machine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1787002 b/results/classifier/gemma3:12b/assembly/1787002 new file mode 100644 index 000000000..b0df46d72 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1787002 @@ -0,0 +1,20 @@ + +disas/i386.c compile error + +QEMU Version: 2.12.1, 3.0.0-rc4 +Compiling with GCC 8.2.0 +System: Plop Linux, 32 bit + +Error: + CC disas/i386.o +/tmp/ccK8tHRs.s: Assembler messages: +/tmp/ccK8tHRs.s:53353: Error: can't resolve `L0' {*ABS* section} - `obuf' {.bss section} + + +The problematic line is in 'disas/i386.c' in the function 'INVLPG_Fixup (int bytemode, int sizeflag)': +strcpy (obuf + strlen (obuf) - 6, alt); + +If I comment out this line, then compiling works without problems. + + +The error comes only on 32 bit. On 64 bit, compiling works without problems. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1793608 b/results/classifier/gemma3:12b/assembly/1793608 new file mode 100644 index 000000000..75432dd3e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1793608 @@ -0,0 +1,17 @@ + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1807675 b/results/classifier/gemma3:12b/assembly/1807675 new file mode 100644 index 000000000..c70def465 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1807675 @@ -0,0 +1,31 @@ + +qemu commit 80422b0: tcg.c crash in temp_load + +As discussed in #1803160 I'm opening a new ticket for the new bug. + +QEMU version: +------------- + +qemu from git, master branch commit 80422b00196a7af4c6efb628fae0ad8b644e98af + +Summary: +-------- + +TCG crashes in i386 and x86_64 when it tries to execute some specific illegal instructions. When running full OS emulation, both the guest system and QEMU crash. + +$ qemu-i386 tcg_crash1.elf +/home/alberto/Documents/qemu/tcg/tcg.c:2863: tcg fatal error +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +zsh: segmentation fault (core dumped) ./qemu/build/i386-linux-user/qemu-i386 tcg_crash1.elf + +Invalid instructions: + +f0 invalid +40 inc eax +a7 cmpsd dword [esi], dword ptr es:[edi] +48 dec eax + +Testcase: +--------- + +Find ELF file attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1815024 b/results/classifier/gemma3:12b/assembly/1815024 new file mode 100644 index 000000000..d4a4f99e3 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1815024 @@ -0,0 +1,16 @@ + +SIGILL on instruction "stck" under qemu-s390x in user mode + +qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). + +This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): + + $ gcc -c -o test.o test.c + $ gcc -c -o rdtsc.o rdtsc.S + $ gcc -o test test.o rdtsc.o + +Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). + +Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. + +Thanks, Giovanni. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1815423 b/results/classifier/gemma3:12b/assembly/1815423 new file mode 100644 index 000000000..94864ec30 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1815423 @@ -0,0 +1,65 @@ + +x86_64 TCG: Incorrect floating point cast to int. + +I used exaample from: +https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c + +#include <stdio.h> +#include <math.h> + +int main(int argc, char** argv) { + float a = INFINITY; + float b = -INFINITY; + float c = NAN; + + printf("float %f %f %f\n", a, b, c); + printf("int %d %d %d\n", (int) a, (int) b, (int) c); + printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned int) c); + printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); + printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, (unsigned long int) c); + + return 0; +} + +And got different results on real computer and on qemu. + +output from real HW is the same as on stackoverflow: + +$ gcc test.c && ./a.out +float inf -inf nan +int -2147483648 -2147483648 -2147483648 +uint 0 0 0 +lint -9223372036854775808 -9223372036854775808 -9223372036854775808 +luint 0 9223372036854775808 9223372036854775808 + + +But on qemu I got another results: + +float inf -inf nan +int 2147483647 -2147483648 2147483647 +uint 4294967295 0 4294967295 +lint 9223372036854775807 -9223372036854775808 -9223372036854775808 +luint 18446744073709551615 9223372036854775808 9223372036854775807 + +qemu launch string: +/qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev user,id=network0 -device e1000,netdev=network0 -kernel my_kernel + + +qemu version: +x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +This bug affect some javascript (surprise) calculations: + +var conversion = "01234567890"; +var x; +var result = conversion[x & 42]; +console.log(result) + + +In example, var x is "undefined" +and when do calculation "x & 42" on js we should get 0 (it is documented feature), but actually got "42" + +and "result" sould be "0" but actually we got "undefined" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1832 b/results/classifier/gemma3:12b/assembly/1832 new file mode 100644 index 000000000..3959f0769 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1832 @@ -0,0 +1,2 @@ + +i386 test registers are not handled diff --git a/results/classifier/gemma3:12b/assembly/1832250 b/results/classifier/gemma3:12b/assembly/1832250 new file mode 100644 index 000000000..c4f218d89 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1832250 @@ -0,0 +1,58 @@ + +arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-compilation + +FROM arm32v6/golang:1.10-alpine + +docker build -t openhorizon/ibm.gps_arm:2.0.7 -f ./Dockerfile.arm . +Sending build context to Docker daemon 110.6kB +Step 1/12 : FROM arm32v6/golang:1.10-alpine +1.10-alpine: Pulling from arm32v6/golang +05276f4299f2: Pull complete +5657e63df536: Pull complete +febca98d0249: Pull complete +5053a7aa5dea: Pull complete +d048463a3701: Pull complete +b628c679d668: Pull complete +Digest: sha256:94c5fd97b17d0e9fe89e011446bedda4784cb0af7a60494989e2a21c0dcba92f +Status: Downloaded newer image for arm32v6/golang:1.10-alpine + ---> 3110964e8c9a +Step 2/12 : RUN apk --no-cache update && apk add git + ---> Running in 14ffb11506bb +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +v3.9.4-24-g4e2ff29bbe [http://dl-cdn.alpinelinux.org/alpine/v3.9/main] +v3.9.4-25-g65097c9cdc [http://dl-cdn.alpinelinux.org/alpine/v3.9/community] +OK: 9547 distinct packages available +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +(1/7) Installing nghttp2-libs (1.35.1-r0) +(2/7) Installing libssh2 (1.8.2-r0) +(3/7) Installing libcurl (7.64.0-r2) +(4/7) Installing libgcc (8.3.0-r0) +(5/7) Installing expat (2.2.6-r0) +(6/7) Installing pcre2 (10.32-r1) +(7/7) Installing git (2.20.1-r0) +Executing busybox-1.29.3-r10.trigger +OK: 18 MiB in 22 packages +Removing intermediate container 14ffb11506bb + ---> 6890ea7ed09b +Step 3/12 : RUN mkdir -p /build/bin + ---> Running in 44e52d78d7b4 +Removing intermediate container 44e52d78d7b4 + ---> 0763afda41d1 +Step 4/12 : COPY src /build/src + ---> 05bab9a72a34 +Step 5/12 : WORKDIR /build + ---> Running in 5a663caff249 +Removing intermediate container 5a663caff249 + ---> 5a6ca53c00de +Step 6/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go get github.com/kellydunn/golang-geo + ---> Running in 05b09ee0c206 +Removing intermediate container 05b09ee0c206 + ---> e68c6e222e51 +Step 7/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go + ---> Running in ea6d2707e35f +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +The command '/bin/sh -c env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go' returned a non-zero code: 139 +make: *** [build] Error 139 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1832422 b/results/classifier/gemma3:12b/assembly/1832422 new file mode 100644 index 000000000..a0d83051e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1832422 @@ -0,0 +1,10 @@ + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1833 b/results/classifier/gemma3:12b/assembly/1833 new file mode 100644 index 000000000..7650a07da --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1833 @@ -0,0 +1,85 @@ + +ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element +Description of problem: +QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits. + +This seems to be a simple issue; I tracked it down to: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382 + +Updating that `+ 1` to a `+ 8` fixes the problem. +Steps to reproduce: +```c +#include <stdio.h> +#include <stdint.h> +#include <string.h> + +void st1q_sme_copy_test(uint8_t* src, uint8_t* dest) { + asm volatile( + "smstart sm\n" + "smstart za\n" + "ptrue p0.b\n" + "mov x12, xzr\n" + "ld1q {za0h.q[w12, 0]}, p0/z, %0\n" + "st1q {za0h.q[w12, 0]}, p0, %1\n" + "smstop za\n" + "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0"); +} + +void print_first_128(uint8_t* data) { + putchar('['); + for (int i = 0; i < 16; i++) { + printf("%02d", data[i]); + if (i != 15) + printf(", "); + } + printf("]\n"); +} + +int main() { + _Alignas(16) uint8_t dest[512] = { }; + _Alignas(16) uint8_t src[512] = { }; + for (int i = 0; i < sizeof(src); i++) + src[i] = i; + puts("Before"); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); + st1q_sme_copy_test(src, dest); + puts("\nAfter "); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); +} +``` + +Compile with (requires at least clang ~14, tested with clang 16):<br/> +`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` + +Run with:<br/> +`qemu-aarch64 -cpu max,sme=on ./qemu_repro` + +It's expected just to copy from `src` to `dest` and output: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +``` + +But currently outputs: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00] +``` +Additional information: +N/A diff --git a/results/classifier/gemma3:12b/assembly/1834399 b/results/classifier/gemma3:12b/assembly/1834399 new file mode 100644 index 000000000..a74be33c8 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1834399 @@ -0,0 +1,37 @@ + +Branch out of range on mips o32 building QEMU + +I build lib32-qemu which is a multilib variant for mips o32 on project Yocto with qemumips64. It finally runs command and fails: + + +mips-wrsmllib32-linux-gcc -meb -mabi=32 -mhard-float -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot +-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1 -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt -pthread -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0 -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include +-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g +-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests +-DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86 +-c arch/AArch64/AArch64InstPrinter.c -o /mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o + + + +And error messages: + +{standard input}: Assembler messages: +{standard input}:38045: Error: branch out of range +{standard input}:38269: Error: branch out of range +{standard input}:38493: Error: branch out of range +{standard input}:38717: Error: branch out of range +{standard input}:38941: Error: branch out of range +{standard input}:39165: Error: branch out of range +{standard input}:39389: Error: branch out of range +{standard input}:39613: Error: branch out of range +{standard input}:39728: Error: branch out of range +{standard input}:39990: Error: branch out of range +{standard input}:40252: Error: branch out of range +{standard input}:40514: Error: branch out of range +{standard input}:40776: Error: branch out of range +{standard input}:41038: Error: branch out of range + + +The gcc version is 9.1. I have verified that gcc 8.3 works. And there is no error when remove option '-Og' with gcc 9.1. + +I am not sure whether it is a defect of gcc 9.1 or capstone. Should it be fixed in capstone? Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1840 b/results/classifier/gemma3:12b/assembly/1840 new file mode 100644 index 000000000..9d1bdcb9c --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1840 @@ -0,0 +1,2 @@ + +Amend RISCV machine default value diff --git a/results/classifier/gemma3:12b/assembly/1841990 b/results/classifier/gemma3:12b/assembly/1841990 new file mode 100644 index 000000000..edb7c3ceb --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1841990 @@ -0,0 +1,39 @@ + +instruction 'denbcdq' misbehaving + +Instruction 'denbcdq' appears to have no effect. Test case attached. + +On ppc64le native: +-- +gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq +$ ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x22080000000000000000000000000000 +$ ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x22080000000000000000000000000001 +$ ./test-denbcdq $(seq 0 99) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x22080000000000000000000000000080 +-- + +With "qemu-ppc64le -cpu power9" +-- +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x0000000000000000000000000000000c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x0000000000000000000000000000001c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x0000000000000000000000000000100c +-- + +I started looking at the code, but I got confused rather quickly. Could be related to endianness? I think denbcdq arrived on the scene before little-endian was a big deal. Maybe something to do with utilizing implicit floating-point register pairs... I don't think the right data is getting to helper_denbcdq, which would point back to the gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc). (Maybe?) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1847 b/results/classifier/gemma3:12b/assembly/1847 new file mode 100644 index 000000000..f310c2535 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1847 @@ -0,0 +1,2 @@ + +TriCore missing ftoq31, ftoq31z, and q31tof instructions diff --git a/results/classifier/gemma3:12b/assembly/1847467 b/results/classifier/gemma3:12b/assembly/1847467 new file mode 100644 index 000000000..44db87523 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1847467 @@ -0,0 +1,17 @@ + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in QEMU \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1849879 b/results/classifier/gemma3:12b/assembly/1849879 new file mode 100644 index 000000000..7ecba8b4c --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1849879 @@ -0,0 +1,11 @@ + +qemu-arm should accept vmrs apsr_nzcv, fpscr on M-profile + +I've noticed that qemu-arm for cortex-M considers +vmrs apsr_nzcv, fpscr +as an illegal instruction. + +In this case, rt==15 means APSR, and the instruction should be accepted and executed like for A-profile. + +I posted a small patch: +https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg06978.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1856706 b/results/classifier/gemma3:12b/assembly/1856706 new file mode 100644 index 000000000..6c7dd2c03 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1856706 @@ -0,0 +1,14 @@ + +target/mips/op_helper.c:971:duplicated branches ? + +qemu-4.2.0/target/mips/op_helper.c:971:8: warning: this condition has identical branches [-Wduplicated-branches] + +Source code is + + if (other_tc == other->current_tc) { + tccause = other->CP0_Cause; + } else { + tccause = other->CP0_Cause; + } + +Possible cut'n'paste error ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1861946 b/results/classifier/gemma3:12b/assembly/1861946 new file mode 100644 index 000000000..7bff608ad --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1861946 @@ -0,0 +1,214 @@ + +qemu-4.2.0 qemu-system-i386 not receive scancode 86 of spanish keyboard (ascii chars '<' & '>') + +Hello. + +I am using qemu-4.2.0 for Windows 64 downloaded from https://qemu.weilnetz.de/w64/, +and I use qemu-system-i386.exe for run Minix 3.1.2a: + + C:\Program Files\qemu> qemu-system-i386 minix3hd.qcow + +All is Ok except the keyboard (spanish). + +Actually the Spanish keyboard has always worked well until the version qemu-2.11.0 included. But after that version and until the current version the Spanish keyboard has worked with some very annoying bugs. + +The bugs that I encountered in the current version 4.2.0 on Windows are: + +1) Scancode 86 (ascii '<') is not received from the Spanish keyboard. + +2) Scancode 41 should be interpreted as 39 (41 -> 39). + +3) in the same way: +12 -> 53 +13 -> 27 +26 -> 12 +27 -> 13 +43 -> 41 +53 -> 43 + +4) Finally and very important in Spain is that scancode 39 should produce the national characters 'ñ' and 'Ñ' + +I have checked the scancodes sent by running a floppy disk image with a boot sector that echoed the scancodes sent by pressing the different keys, so the errors are not due in any case to the operating system, but to the virtual machine or at most to the BIOS. + +In Minix 3.1.2a I tried to alleviate the errors by modifying the keymap: /usr/lib/keymaps/spanish.map. I have managed to solve all the errors except the one corresponding to scancode 86 (ascii '<') since when the key is pressed on the Spanish keyboard the scancode 86 is not sent. + +I accompany the modified keymap: https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/R3.1.2/drivers/tty/keymaps/spanish.src for it could be clarifying in any way. + +Thank you very much for qemu and the new version 4.2.0. Apart from these small details, all the improvements that have been included are greatly appreciated. + +Greetings. Pedro Pablo. + +------------------------- spanish.src (modified #if 0 #else #endif) ------------------------- + +/* Keymap for Spanish MF-2 keyboard. */ +/* Modified by Javier Garcia Martin <email address hidden> */ + +u16_t keymap[NR_SCAN_CODES * MAP_COLS] = { + +/* scan-code !Shift Shift Alt AltGr Alt+Sh Ctrl */ +/* +==================================================================== +*/ +/* 00 - none */ 0, 0, 0, 0, 0, 0, +/* 01 - ESC */ C('['), C('['), CA('['),C('['), C('['), C('['), +/* 02 - '1' */ '1', '!', A('1'), '|', '!', C('A'), +/* 03 - '2' */ '2', '"', A('2'), '@', '"', C('@'), +/* 04 - '3' */ '3', 0372, A('3'), '#', 0372, C('C'), +/* 05 - '4' */ '4', '$', A('4'), '4', '$', C('D'), +/* 06 - '5' */ '5', '%', A('5'), '5', '%', C('E'), +/* 07 - '6' */ '6', '&', A('6'), 0252, '&', C('F'), +/* 08 - '7' */ '7', '/', A('7'), '{', '/', C('G'), +/* 09 - '8' */ '8', '(', A('8'), '(', '(', C('H'), +/* 10 - '9' */ '9', ')', A('9'), ')', ')', C('I'), +/* 11 - '0' */ '0', '=', A('0'), '=', '=', C('@'), +#if 0 +/* 12 - '-' */ '\'', '?', A('\''),'?', '?', C('_'), /* debería ser como la (53) */ +#else +/* 53 - '/' */ '-', '_', A('-'), '-', '_', C('@'), +#endif +#if 0 +/* 13 - '=' */ 0255, 0250, A(0255),0250, 0250, C('@'), /* deberia ser como la (27) */ +#else +/* 27 - ']' */ '+', '*', A('+'), ']', '*', C(']'), +#endif +/* 14 - BS */ C('H'), C('H'), CA('H'),C('H'), C('H'), 0177, +/* 15 - TAB */ C('I'), C('I'), CA('I'),C('I'), C('I'), C('I'), +/* 16 - 'q' */ L('q'), 'Q', A('q'), 'q', 'Q', C('Q'), +/* 17 - 'w' */ L('w'), 'W', A('w'), 'w', 'W', C('W'), +/* 18 - 'e' */ L('e'), 'E', A('e'), 'e', 'E', C('E'), +/* 19 - 'r' */ L('r'), 'R', A('r'), 'r', 'R', C('R'), +/* 20 - 't' */ L('t'), 'T', A('t'), 't', 'T', C('T'), +/* 21 - 'y' */ L('y'), 'Y', A('y'), 'y', 'Y', C('Y'), +/* 22 - 'u' */ L('u'), 'U', A('u'), 'u', 'U', C('U'), +/* 23 - 'i' */ L('i'), 'I', A('i'), 'i', 'I', C('I'), +/* 24 - 'o' */ L('o'), 'O', A('o'), 'o', 'O', C('O'), +/* 25 - 'p' */ L('p'), 'P', A('p'), 'p', 'P', C('P'), +#if 0 +/* 26 - '[' */ '`', '^', A('`'),'[', '^', C('['), /* debería ser como la (12) */ +#else +/* 12 - '-' */ '\'', '?', A('\''),'?', '?', C('_'), +#endif +#if 0 +/* 27 - ']' */ '+', '*', A('+'), ']', '*', C(']'), /* deberia ser como la (13) */ +#else +/* 13 - '=' */ 0255, 0250, A(0255),0250, 0250, C('@'), +#endif +/* 28 - CR/LF */ C('M'), C('M'), CA('M'),C('M'), C('M'), C('J'), +/* 29 - Ctrl */ CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, +/* 30 - 'a' */ L('a'), 'A', A('a'), 'a', 'A', C('A'), +/* 31 - 's' */ L('s'), 'S', A('s'), 's', 'S', C('S'), +/* 32 - 'd' */ L('d'), 'D', A('d'), 'd', 'D', C('D'), +/* 33 - 'f' */ L('f'), 'F', A('f'), 'f', 'F', C('F'), +/* 34 - 'g' */ L('g'), 'G', A('g'), 'g', 'G', C('G'), +/* 35 - 'h' */ L('h'), 'H', A('h'), 'h', 'H', C('H'), +/* 36 - 'j' */ L('j'), 'J', A('j'), 'j', 'J', C('J'), +/* 37 - 'k' */ L('k'), 'K', A('k'), 'k', 'K', C('K'), +/* 38 - 'l' */ L('l'), 'L', A('l'), 'l', 'L', C('L'), +#if 0 +/* 39 - ';' */ L(0244),0245, A(0244),0244, 0245, C('@'), /* deberia ser como la (26) */ +#else +/* 26 - '[' */ '`', '^', A('`'),'[', '^', C('['), +#endif +/* 40 - '\'' */ '\'', '"', A('\''),'{', '"', C('@'), +#if 0 +/* 41 - '`' */ 0247, 0246, A(0247),'\\', 0246, C('@'), /* deberia ser como la (ñÑ) */ +#else +/* 39 - ';' */ L(0244),0245, A(0244),0244, 0245, C('@'), +#endif +/* 42 - l. SHIFT*/ SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, +#if 0 +/* 43 - '\\' */ L(0207),0200, A(0207),'}', 0200, C('@'), /* deberia ser como la (41) */ +#elif 0 +/* 41 - '`' */ 0247, 0246, A(0247),'\\', 0246, C('@'), +#else +/* 41 - '`' */ '<', '>', A('<'), '\\', 0246, C('@'), /* añadimos < y > */ +#endif +/* 44 - 'z' */ L('z'), 'Z', A('z'), 'z', 'Z', C('Z'), +/* 45 - 'x' */ L('x'), 'X', A('x'), 'x', 'X', C('X'), +/* 46 - 'c' */ L('c'), 'C', A('c'), 'c', 'C', C('C'), +/* 47 - 'v' */ L('v'), 'V', A('v'), 'v', 'V', C('V'), +/* 48 - 'b' */ L('b'), 'B', A('b'), 'b', 'B', C('B'), +/* 49 - 'n' */ L('n'), 'N', A('n'), 'n', 'N', C('N'), +/* 50 - 'm' */ L('m'), 'M', A('m'), 'm', 'M', C('M'), +/* 51 - ',' */ ',', ';', A(','), ',', ';', C('@'), +/* 52 - '.' */ '.', ':', A('.'), '.', ':', C('@'), +#if 0 +/* 53 - '/' */ '-', '_', A('-'), '-', '_', C('@'), /* deberia ser como la (43) */ +#else +/* 43 - '\\' */ L(0207),0200, A(0207),'}', 0200, C('@'), +#endif +/* 54 - r. SHIFT*/ SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, +/* 55 - '*' */ '*', '*', A('*'), '*', '*', C('M'), +/* 56 - ALT */ ALT, ALT, ALT, ALT, ALT, ALT, +/* 57 - ' ' */ ' ', ' ', A(' '), ' ', ' ', C('@'), +/* 58 - CapsLck */ CALOCK, CALOCK, CALOCK, CALOCK, CALOCK, CALOCK, +/* 59 - F1 */ F1, SF1, AF1, AF1, ASF1, CF1, +/* 60 - F2 */ F2, SF2, AF2, AF2, ASF2, CF2, +/* 61 - F3 */ F3, SF3, AF3, AF3, ASF3, CF3, +/* 62 - F4 */ F4, SF4, AF4, AF4, ASF4, CF4, +/* 63 - F5 */ F5, SF5, AF5, AF5, ASF5, CF5, +/* 64 - F6 */ F6, SF6, AF6, AF6, ASF6, CF6, +/* 65 - F7 */ F7, SF7, AF7, AF7, ASF7, CF7, +/* 66 - F8 */ F8, SF8, AF8, AF8, ASF8, CF8, +/* 67 - F9 */ F9, SF9, AF9, AF9, ASF9, CF9, +/* 68 - F10 */ F10, SF10, AF10, AF10, ASF10, CF10, +/* 69 - NumLock */ NLOCK, NLOCK, NLOCK, NLOCK, NLOCK, NLOCK, +/* 70 - ScrLock */ SLOCK, SLOCK, SLOCK, SLOCK, SLOCK, SLOCK, +/* 71 - Home */ HOME, '7', AHOME, AHOME, '7', CHOME, +/* 72 - CurUp */ UP, '8', AUP, AUP, '8', CUP, +/* 73 - PgUp */ PGUP, '9', APGUP, APGUP, '9', CPGUP, +/* 74 - '-' */ NMIN, '-', ANMIN, ANMIN, '-', CNMIN, +/* 75 - Left */ LEFT, '4', ALEFT, ALEFT, '4', CLEFT, +/* 76 - MID */ MID, '5', AMID, AMID, '5', CMID, +/* 77 - Right */ RIGHT, '6', ARIGHT, ARIGHT, '6', CRIGHT, +/* 78 - '+' */ PLUS, '+', APLUS, APLUS, '+', CPLUS, +/* 79 - End */ END, '1', AEND, AEND, '1', CEND, +/* 80 - Down */ DOWN, '2', ADOWN, ADOWN, '2', CDOWN, +/* 81 - PgDown */ PGDN, '3', APGDN, APGDN, '3', CPGDN, +/* 82 - Insert */ INSRT, '0', AINSRT, AINSRT, '0', CINSRT, +/* 83 - Delete */ 0177, '.', A(0177),0177, '.', 0177, +/* 84 - Enter */ C('M'), C('M'), CA('M'),C('M'), C('M'), C('J'), +/* 85 - ??? */ 0, 0, 0, 0, 0, 0, +/* 86 - ??? */ '<', '>', A('<'), '<', '>', C('@'), +/* 87 - F11 */ F11, SF11, AF11, AF11, ASF11, CF11, +/* 88 - F12 */ F12, SF12, AF12, AF12, ASF12, CF12, +/* 89 - ??? */ 0, 0, 0, 0, 0, 0, +/* 90 - ??? */ 0, 0, 0, 0, 0, 0, +/* 91 - ??? */ 0, 0, 0, 0, 0, 0, +/* 92 - ??? */ 0, 0, 0, 0, 0, 0, +/* 93 - ??? */ 0, 0, 0, 0, 0, 0, +/* 94 - ??? */ 0, 0, 0, 0, 0, 0, +/* 95 - ??? */ 0, 0, 0, 0, 0, 0, +/* 96 - EXT_KEY */ EXTKEY, EXTKEY, EXTKEY, EXTKEY, EXTKEY, EXTKEY, +/* 97 - ??? */ 0, 0, 0, 0, 0, 0, +/* 98 - ??? */ 0, 0, 0, 0, 0, 0, +/* 99 - ??? */ 0, 0, 0, 0, 0, 0, +/*100 - ??? */ 0, 0, 0, 0, 0, 0, +/*101 - ??? */ 0, 0, 0, 0, 0, 0, +/*102 - ??? */ 0, 0, 0, 0, 0, 0, +/*103 - ??? */ 0, 0, 0, 0, 0, 0, +/*104 - ??? */ 0, 0, 0, 0, 0, 0, +/*105 - ??? */ 0, 0, 0, 0, 0, 0, +/*106 - ??? */ 0, 0, 0, 0, 0, 0, +/*107 - ??? */ 0, 0, 0, 0, 0, 0, +/*108 - ??? */ 0, 0, 0, 0, 0, 0, +/*109 - ??? */ 0, 0, 0, 0, 0, 0, +/*110 - ??? */ 0, 0, 0, 0, 0, 0, +/*111 - ??? */ 0, 0, 0, 0, 0, 0, +/*112 - ??? */ 0, 0, 0, 0, 0, 0, +/*113 - ??? */ 0, 0, 0, 0, 0, 0, +/*114 - ??? */ 0, 0, 0, 0, 0, 0, +/*115 - ??? */ 0, 0, 0, 0, 0, 0, +/*116 - ??? */ 0, 0, 0, 0, 0, 0, +/*117 - ??? */ 0, 0, 0, 0, 0, 0, +/*118 - ??? */ 0, 0, 0, 0, 0, 0, +/*119 - ??? */ 0, 0, 0, 0, 0, 0, +/*120 - ??? */ 0, 0, 0, 0, 0, 0, +/*121 - ??? */ 0, 0, 0, 0, 0, 0, +/*122 - ??? */ 0, 0, 0, 0, 0, 0, +/*123 - ??? */ 0, 0, 0, 0, 0, 0, +/*124 - ??? */ 0, 0, 0, 0, 0, 0, +/*125 - ??? */ 0, 0, 0, 0, 0, 0, +/*126 - ??? */ 0, 0, 0, 0, 0, 0, +/*127 - ??? */ 0, 0, 0, 0, 0, 0 +}; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1862167 b/results/classifier/gemma3:12b/assembly/1862167 new file mode 100644 index 000000000..1d0a95145 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1862167 @@ -0,0 +1,4 @@ + +Variation of SVE register size (qemu-user-aarch64) + +Specification of ARMv8-A SVE extention allows various values for the size of the SVE register. On the other hand, it seems that the current qemu-aarch64 supports only the maximum length of 2048 bits as the SVE register size. I am writing an assembler program for a CPU that is compliant with ARMv8-A + SVE and has a 512-bit SVE register, but when this is run with qemu-user-aarch64, a 2048-bit load / store instruction is executed This causes a segmentation fault. Shouldn't qeum-user-aarch64 have an option to specify the SVE register size? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1879955 b/results/classifier/gemma3:12b/assembly/1879955 new file mode 100644 index 000000000..1bd265220 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1879955 @@ -0,0 +1,24 @@ + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? + +In target/i386/seg_helper.c:switch_tss_ra() we have the following code to load registers from a 16-bit TSS struct: + + /* 16 bit */ + new_cr3 = 0; + new_eip = cpu_lduw_kernel_ra(env, tss_base + 0x0e, retaddr); + new_eflags = cpu_lduw_kernel_ra(env, tss_base + 0x10, retaddr); + for (i = 0; i < 8; i++) { + new_regs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x12 + i * 2), + retaddr) | 0xffff0000; + } + for (i = 0; i < 4; i++) { + new_segs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x22 + i * 4), + retaddr); + } + new_ldt = cpu_lduw_kernel_ra(env, tss_base + 0x2a, retaddr); + +This doesn't match up with the structure described here: https://www.sandpile.org/x86/tss.htm -- which has only 2-byte slots for the segment registers. It also makes the 3rd segreg use the same offset as the LDTR, which is very suspicious. I suspect that this should use "(0x22 + i * 2)". + +The code later in the same function that stores the segment registers to the struct has the same bug. + +Found by code inspection; I don't have a test case to check this. As a non-x86-expert I'm just going to file a bug report in case somebody else feels like confirming the issue and sending a patch. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1881004 b/results/classifier/gemma3:12b/assembly/1881004 new file mode 100644 index 000000000..3da0caeb0 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1881004 @@ -0,0 +1,51 @@ + +fpu/softfloat.c: error: bitwise negation of a boolean expression + +Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: + + CC lm32-softmmu/fpu/softfloat.o +fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3423:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~ ( ( (uint64_t) ( absZ1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3483:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~(((uint64_t)(absZ1<<1) == 0) & roundNearestEven); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3606:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3760:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x200 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3987:21: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4003:22: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig0 &= ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4273:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig1 &= ~ ( ( zSig2 + zSig2 == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +8 errors generated. + +$ clang -v +clang version 10.0.0-4ubuntu1 +Target: aarch64-unknown-linux-gnu + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1883984 b/results/classifier/gemma3:12b/assembly/1883984 new file mode 100644 index 000000000..1c5715670 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1883984 @@ -0,0 +1,27 @@ + +QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x + +In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered +that some of my own numerical programs, and also a GNU configure script for at +least one package with CC=clang, would cause an instant crash of the VM, sometimes +also destroying recently opened files, and producing long strings of NUL characters +in /var/log/syslog in the S/390 guest O/S. + +Further detective work narrowed the cause of the crash down to a single IBM S/390 +instruction: sqxbr (128-bit IEEE 754 square root). Here is a one-line program +that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0 +(Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920 +workstation with an Intel Xeon Platinum 8253 CPU], and also on QEMU emulator +version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x. + +% cat bug-sqrtl-one-line.c +int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);} + +% cc bug-sqrtl-one-line.c && ./a.out +Segmentation fault (core dumped) + +The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c +starting at line 7619. I have NOT attempted to run the qemu-system-s390x executable +under a debugger. However, I observe that S/390 is the only CPU family that I know of, +except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware. +Thus, this instruction bug may not have been seen before. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1885718 b/results/classifier/gemma3:12b/assembly/1885718 new file mode 100644 index 000000000..13a4531de --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1885718 @@ -0,0 +1,10 @@ + +qemu/target/mips/op_helper.c:943:5: style:inconclusive: Found duplicate branches for 'if' and 'else' + +Source code is + + if (other_tc == other->current_tc) { + tccause = other->CP0_Cause; + } else { + tccause = other->CP0_Cause; + } \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1909392 b/results/classifier/gemma3:12b/assembly/1909392 new file mode 100644 index 000000000..57873e2c8 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1909392 @@ -0,0 +1,21 @@ + +qemu-arm crashes (SIGSEGV) when executing push instruction + +Dear all, +I am afraid I found a problem, it seems like qemu-arm crashes when executing assembly push instruction. +I use qemu version 5.2.0, but it checked an older version (4.2.1) and the problem was also present. I start qemu using "qemu-arm -cpu cortex-m4 -singlestep -g 1234 <path to elf file>" +Callstack before crash (host) +#0 0x000055555575961f in stl_he_p (ptr=0x2002fffc, v=0) at /home/faust1002/Programming/qemu/qemu-5.2.0/include/qemu/bswap.h:353 +#1 0x0000555555759716 in stl_le_p (ptr=0x2002fffc, v=0) at /home/faust1002/Programming/qemu/qemu-5.2.0/include/qemu/bswap.h:395 +#2 0x000055555575d3c3 in tcg_qemu_tb_exec (env=0x555555d28050, tb_ptr=0x7fffe800010a "\r\b") at ../tcg/tci.c:1221 +#3 0x00005555556bd982 in cpu_tb_exec (cpu=0x555555d1fd70, itb=0x7fffe8000000) at ../accel/tcg/cpu-exec.c:178 +#4 0x00005555556be57e in cpu_loop_exec_tb (cpu=0x555555d1fd70, tb=0x7fffe8000000, last_tb=0x7fffffffd8a8, tb_exit=0x7fffffffd8a0) at ../accel/tcg/cpu-exec.c:658 +#5 0x00005555556be7ea in cpu_exec (cpu=0x555555d1fd70) at ../accel/tcg/cpu-exec.c:771 +#6 0x000055555560af1d in cpu_loop (env=0x555555d28050) at ../linux-user/arm/cpu_loop.c:237 +#7 0x00005555557415a7 in main (argc=7, argv=0x7fffffffe0f8, envp=0x7fffffffe138) at ../linux-user/main.c:861 +Callstack before crash (target) +Program received signal SIGSEGV, Segmentation fault. +Reset_Handler () at startup.s:48 +48 push {r14} +Please find the elf file I use attached. +Kind regards \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1912065 b/results/classifier/gemma3:12b/assembly/1912065 new file mode 100644 index 000000000..28f14045f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1912065 @@ -0,0 +1,33 @@ + +Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d + +QEMU segfaults to NULL dereference in tcg/optimize.c:212 semi-randomly after commit 7c79721606be11b5bc556449e5bcbc331ef6867d + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 +Exception Note: EXC_CORPSE_NOTIFY + +... + +Thread 4 Crashed: +0 qemu-system-ppc 0x0000000109cd26d2 tcg_opt_gen_mov + 178 (optimize.c:212) +1 qemu-system-ppc 0x0000000109ccf838 tcg_optimize + 5656 +2 qemu-system-ppc 0x0000000109c27600 tcg_gen_code + 64 (tcg.c:4490) +3 qemu-system-ppc 0x0000000109c17b6d tb_gen_code + 493 (translate-all.c:1952) +4 qemu-system-ppc 0x0000000109c16085 tb_find + 41 (cpu-exec.c:454) [inlined] +5 qemu-system-ppc 0x0000000109c16085 cpu_exec + 2117 (cpu-exec.c:810) +6 qemu-system-ppc 0x0000000109c09ac3 tcg_cpus_exec + 35 (tcg-cpus.c:57) +7 qemu-system-ppc 0x0000000109c75edd rr_cpu_thread_fn + 445 (tcg-cpus-rr.c:217) +8 qemu-system-ppc 0x0000000109e41fae qemu_thread_start + 126 (qemu-thread-posix.c:521) +9 libsystem_pthread.dylib 0x00007fff2038e950 _pthread_start + 224 +10 libsystem_pthread.dylib 0x00007fff2038a47b thread_start + 15 + +Here the crash is in tcg/optimize.c line 212: + + mask = si->mask; + +"si" is NULL. The NULL value arises from tcg/optimize.c line 198: + + si = ts_info(src_ts); + +I did not attempt to determine the root cause of this issue, however. It clearly is related to the "tcg/optimize" changes in this commit. The previous commit c0dd6654f207810b16a75b673258f5ce2ceffbf0 doesn't crash. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1912934 b/results/classifier/gemma3:12b/assembly/1912934 new file mode 100644 index 000000000..0be6f924b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1912934 @@ -0,0 +1,18 @@ + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1915327 b/results/classifier/gemma3:12b/assembly/1915327 new file mode 100644 index 000000000..ac6a4a6a1 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1915327 @@ -0,0 +1,35 @@ + +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 diff --git a/results/classifier/gemma3:12b/assembly/1916394 b/results/classifier/gemma3:12b/assembly/1916394 new file mode 100644 index 000000000..ea0ee9e5d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1916394 @@ -0,0 +1,19 @@ + +[git] Cannot build qemu: FAILED: target/hexagon/semantics_generated.pyinc + +Hello. + +I tried to build Qemu at commit 4115aec9af2a3de5fa89a0b1daa12debcd7741ff but it stops with this error message: + +[code] +Found ninja-1.10.2 at /usr/bin/ninja +[632/9068] Generating semantics_generated.pyinc with a custom command +FAILED: target/hexagon/semantics_generated.pyinc +@INPUT@ target/hexagon/semantics_generated.pyinc +/bin/sh: line 1: @INPUT@: command not found +[637/9068] Compiling C object fsdev/vi...proxy-helper.p/virtfs-proxy-helper.c.o +ninja: build stopped: subcommand failed. +[/code] + +ninja version: 1.10.2 +meson version: 0.57.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1925512 b/results/classifier/gemma3:12b/assembly/1925512 new file mode 100644 index 000000000..2415ad2b5 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1925512 @@ -0,0 +1,19 @@ + +UNDEFINED case for instruction BLX + +Hi + +I refer to the instruction BLX imm (T2 encoding) in ARMv7 (Thumb mode). + +11110 S imm10H 11 J1 0 J2 imm10L H + + +if H == '1' then UNDEFINED; +I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:'00', 32); +targetInstrSet = InstrSet_A32; +if InITBlock() && !LastInITBlock() then UNPREDICTABLE; + +According to the manual, if H equals to 1, this instruction should be an UNDEFINED instruction. However, it seems QEMU does not check this constraint in function trans_BLX_i. Thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1926277 b/results/classifier/gemma3:12b/assembly/1926277 new file mode 100644 index 000000000..348343693 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1926277 @@ -0,0 +1,38 @@ + +MIPS MT dvpe does not regard VPEConf0.MVP + +Hi, + +According to MIPS32® Architecture for Programmers VolumeIV-f: The MIPS® MT Application-Specific Extension to the MIPS32® Architecture, for instruction: dvpe, evpe: + +If the VPE executing the instruction is not a Master VPE, with the MVP bit of the VPEConf0 register set, the EVP bit is unchanged by the instruction. + +The pseudo code is: + +data ← MVPControl +GPR[rt] ← data +if(VPEConf0.MVP = 1) then + MVPControl.EVP ← sc +endif + +However the helper functions of dvpe, evpe does not regard the VPEConf0.MVP bit, namely, it does not check if the VPE is a master VPE. Code is copied below as: + +target_ulong helper_dvpe(CPUMIPSState *env) +{ + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + + CPU_FOREACH(other_cs) { + MIPSCPU *other_cpu = MIPS_CPU(other_cs); + /* Turn off all VPEs except the one executing the dvpe. */ + if (&other_cpu->env != env) { + other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); + mips_vpe_sleep(other_cpu); + } + } + return prev; +} + +Is this a bug? + +QEMU head commit: 0cef06d18762374c94eb4d511717a4735d668a24 is checked. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/1934 b/results/classifier/gemma3:12b/assembly/1934 new file mode 100644 index 000000000..1201b892e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1934 @@ -0,0 +1,25 @@ + +Build failure on s390x with Clang 17 due to int128 alignment used in `__sync_` operations +Description of problem: +We experienced this downstream, but filing this here since the code still seems to be the same in git. + +https://reviews.llvm.org/D143813 introduced this warning since, according to the description, `__int128` +needs to be 8-byte aligned on s390 but the code in `host/include/generic/host/atomic128-ldst.h` unconditionally uses 16-byte alignment. + +The output is: + +``` +In file included from ../accel/tcg/cputlb.c:32: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:62: +/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-ldst.h:68:15: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment] + 68 | } while (!__sync_bool_compare_and_swap_16(ptr_align, old, new.i)); + | ^ +In file included from ../accel/tcg/cputlb.c:32: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:61: +/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-cas.h:36:11: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment] + 36 | r.i = __sync_val_compare_and_swap_16(ptr_align, c.i, n.i); + | ^ +2 errors generated. +``` diff --git a/results/classifier/gemma3:12b/assembly/1942 b/results/classifier/gemma3:12b/assembly/1942 new file mode 100644 index 000000000..d488eadf1 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1942 @@ -0,0 +1,10 @@ + +GCC segfault (ICE) while building in qemu-user sparc64 +Steps to reproduce: +1. Follow Qemu-user [documentation](https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot) for Sparc64 +2. Attempt to build libpaper: `emerge -v app-text/libpaper-2.1.0:0/2` + +Resulting compilation will fail with an internal compilation error. +Additional information: +This can be tested by trying to [compile](/uploads/ba4585ea75fa157a34bf8f3ffb64bded/H1NM.i) with `gcc -mcpu=ultrasparc -O2 -c` instead of building the entire libpaper package. +Here is the [output.](/uploads/30a154eb602caa5a8b1bd82a6271d6d8/output.txt) diff --git a/results/classifier/gemma3:12b/assembly/1955 b/results/classifier/gemma3:12b/assembly/1955 new file mode 100644 index 000000000..046b55659 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1955 @@ -0,0 +1,27 @@ + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/gemma3:12b/assembly/1970 b/results/classifier/gemma3:12b/assembly/1970 new file mode 100644 index 000000000..3b2ef2158 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/1970 @@ -0,0 +1,2 @@ + +A64 LDRA decode scales the immediate by wrong amount diff --git a/results/classifier/gemma3:12b/assembly/2076 b/results/classifier/gemma3:12b/assembly/2076 new file mode 100644 index 000000000..96aa84e7d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2076 @@ -0,0 +1,2 @@ + +stringop-overread warning in tests/tcg/multiarch/sha1.c diff --git a/results/classifier/gemma3:12b/assembly/2083 b/results/classifier/gemma3:12b/assembly/2083 new file mode 100644 index 000000000..091fb9768 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2083 @@ -0,0 +1,112 @@ + +AArch64 SME SMOPA (4-way) outer product instruction gives incorrect result +Description of problem: +The SME SMOPA (4-way) instruction ([spec](https://developer.arm.com/documentation/ddi0602/2023-09/SME-Instructions/SMOPA--4-way---Signed-integer-sum-of-outer-products-and-accumulate-?lang=en)) is giving incorrect result. Example below for 8-bit variant, which is equivalent to following Python example (128-bit VL) to make it clearer: + +``` +import numpy as np +vl = 128 +esize = 32 +dim = vl // esize + +A = range(16) +B = range(16, 32) +C = np.zeros((4, 4,), dtype=np.int32) + +for row in range(dim): + for col in range(dim): + for k in range(4): + C[row, col] += A[4*row + k] * B[4*col + k] + +print(C) + +[[ 110 134 158 182] + [ 390 478 566 654] + [ 670 822 974 1126] + [ 950 1166 1382 1598]] +``` + +main.c +``` +#include <stdio.h> +#include <stdint.h> + +void foo(int *dst); + +int main() { + int32_t dst[16]; + foo(dst); + + // This should print: + // >>> 110 134 158 182 + // >>> 390 478 566 654 + // >>> 670 822 974 1126 + // >>> 950 1166 1382 1598 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%d ", dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S + +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.b + index z0.b, #0, #1 + mov z1.d, z0.d + add z1.b, z1.b, #16 + + zero {za} + smopa za0.s, p0/m, p0/m, z0.b, z1.b + + // Read the first 4x4 sub-matrix of elements from tile 0: + mov w12, #0 + mova z0.s, p0/m, za0h.s[w12, #0] + mova z1.s, p0/m, za0h.s[w12, #1] + mova z2.s, p0/m, za0h.s[w12, #2] + mova z3.s, p0/m, za0h.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme main.c foo.S +$ ~/qemu/build/qemu-aarch64 -cpu max,sme128=on a.out +>>> 110 478 158 654 +>>> 0 0 0 0 +>>> 670 1166 974 1598 +>>> 0 0 0 0 +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/2106 b/results/classifier/gemma3:12b/assembly/2106 new file mode 100644 index 000000000..06e550235 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2106 @@ -0,0 +1,56 @@ + +QEMU build fail on Solaris 11.4 because "FSCALE" #defined by sys/param.h +Description of problem: +Building `target/arm/tcg/translate-sve.c` fails on Solaris 11.4 because system's +`/usr/include/sys/param.h` has `#define FSCALE (1 << FSHIFT)` which results +in `DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn)` at `translate-sve.c:3864` +attempting to expand the `#define` substitution instead of the text `FSCALE`.<p>I have not determined what the sequence of includes was that brought in `sys/param.h`<p>A workaround is to `#undef FSCALE`, but that may not be an appropriate long-term fix. +Steps to reproduce: +1. mkdir build && cd build +2. ../configure --disable-docs --disable-rdma --enable-slirp +3. gmake +Additional information: +Full diagnostic output: +``` +[1865/5402] Compiling C object libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o +FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o +cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/glib-2.0 -I/usr/lib/sparcv9/glib-2.0/include -I/usr/include/pcre -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -Wshadow=local -iquote . -iquote /opt/qemu -iquote /opt/qemu/include -iquote /opt/qemu/host/include/generic -iquote /opt/qemu/tcg/sparc64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -fPIE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_tcg_translate-sve.c.o -c ../target/arm/tcg/translate-sve.c +In file included from ../target/arm/tcg/translate-sve.c:21: +../target/arm/tcg/translate.h:728:17: error: pasting "trans_" and "(" does not give a valid preprocessing token + 728 | static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \ + | ^~~~~~ +../target/arm/tcg/translate-sve.c:3854:5: note: in expansion of macro ‘TRANS_FEAT’ + 3854 | TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a) + | ^~~~~~~~~~ +../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’ + 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn) + | ^~~~~~~~~~ +../target/arm/tcg/translate-sve.c:3864:12: error: expected declaration specifiers or ‘...’ before numeric constant + 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn) + | ^~~~~~ +../target/arm/tcg/translate.h:728:25: note: in definition of macro ‘TRANS_FEAT’ + 728 | static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \ + | ^~~~ +../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’ + 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn) + | ^~~~~~~~~~ +../target/arm/tcg/translate.h:728:47: error: pasting "arg_" and "(" does not give a valid preprocessing token + 728 | static bool trans_##NAME(DisasContext *s, arg_##NAME *a) \ + | ^~~~ +../target/arm/tcg/translate-sve.c:3854:5: note: in expansion of macro ‘TRANS_FEAT’ + 3854 | TRANS_FEAT(NAME, FEAT, gen_gvec_fpst_arg_zpzz, name##_zpzz_fns[a->esz], a) + | ^~~~~~~~~~ +../target/arm/tcg/translate-sve.c:3864:1: note: in expansion of macro ‘DO_ZPZZ_FP’ + 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn) + | ^~~~~~~~~~ +In file included from ../target/arm/tcg/translate-sve.c:86: +libqemu-aarch64-softmmu.fa.p/decode-sve.c.inc:1112:13: warning: ‘trans_FSCALE’ used but never defined + 1112 | static bool trans_FSCALE(DisasContext *ctx, arg_FSCALE *a); + | ^~~~~~~~~~~~ +../target/arm/tcg/translate-sve.c:3864:30: warning: ‘sve_fscalbn_zpzz_fns’ defined but not used [-Wunused-const-variable=] + 3864 | DO_ZPZZ_FP(FSCALE, aa64_sve, sve_fscalbn) + | ^~~~~~~~~~~ +../target/arm/tcg/translate-sve.c:3850:42: note: in definition of macro ‘DO_ZPZZ_FP’ + 3850 | static gen_helper_gvec_4_ptr * const name##_zpzz_fns[4] = { \ + | ^~~~ +``` diff --git a/results/classifier/gemma3:12b/assembly/2136 b/results/classifier/gemma3:12b/assembly/2136 new file mode 100644 index 000000000..f813b7987 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2136 @@ -0,0 +1,36 @@ + +on loongarch host, LSX vec get wrong result +Description of problem: +on loongarch host, the lsx insns get wrong result. +Steps to reproduce: +1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' +2. build test code 'gcc --static test.c -o test' +3. run './build/qemu-loongarch64 test' +Additional information: +run 'qemu-loongarch64 test' +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: ffffffff +5: 0 +6: ffffffff +7: ffffffff` + +and the 6 or 7 may be ffffff or 0. + +run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: 0 +5: 0 +6: 0 +7: 0` + +for more infomation see log.txt diff --git a/results/classifier/gemma3:12b/assembly/2175 b/results/classifier/gemma3:12b/assembly/2175 new file mode 100644 index 000000000..55800e1bd --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2175 @@ -0,0 +1,39 @@ + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/2203 b/results/classifier/gemma3:12b/assembly/2203 new file mode 100644 index 000000000..54c92dde6 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2203 @@ -0,0 +1,2 @@ + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/gemma3:12b/assembly/2222 b/results/classifier/gemma3:12b/assembly/2222 new file mode 100644 index 000000000..52986cb16 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2222 @@ -0,0 +1,2 @@ + +elf2dmp has endianness bugs diff --git a/results/classifier/gemma3:12b/assembly/2236 b/results/classifier/gemma3:12b/assembly/2236 new file mode 100644 index 000000000..a488f3a66 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2236 @@ -0,0 +1,2 @@ + +32-bit PPC CPUs are reported based on 64-bit base CPU diff --git a/results/classifier/gemma3:12b/assembly/2302 b/results/classifier/gemma3:12b/assembly/2302 new file mode 100644 index 000000000..fa817180d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2302 @@ -0,0 +1,26 @@ + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/gemma3:12b/assembly/2317 b/results/classifier/gemma3:12b/assembly/2317 new file mode 100644 index 000000000..3cf8a0620 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2317 @@ -0,0 +1,39 @@ + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/gemma3:12b/assembly/2320 b/results/classifier/gemma3:12b/assembly/2320 new file mode 100644 index 000000000..fc4a9ac92 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2320 @@ -0,0 +1,2 @@ + +-Wchar-subscripts warnings in target/i386/tcg/decode-new.c.inc diff --git a/results/classifier/gemma3:12b/assembly/2336 b/results/classifier/gemma3:12b/assembly/2336 new file mode 100644 index 000000000..e44a9f940 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2336 @@ -0,0 +1,24 @@ + +qemu-x86_64 crash on LoongArch +Description of problem: + +Steps to reproduce: +1. build a static hello test on x86_64 machine. +2. build qemu-x86_64 on LoongArch. +3. run 'qemu-x86_64 hello 'on LoongArch. +Additional information: +1 result + +[root@localhost qemu]# ./build/qemu-x86_64 ~/hello +Bus error (core dumped) + +2 Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 + +3 full log with -d in_asm,op,out_asm,strace +see log.txt + +[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt) + +[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64) + +[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello) diff --git a/results/classifier/gemma3:12b/assembly/2371 b/results/classifier/gemma3:12b/assembly/2371 new file mode 100644 index 000000000..4c02e37db --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2371 @@ -0,0 +1,53 @@ + +A bug in RISC-V froundnx.h instruction +Description of problem: +According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN. +However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h: +``` +// target/riscv/fpu_helper.c +uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1) +{ + float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h. + frs1 = float16_round_to_int(frs1, &env->fp_status); + return nanbox_h(env, frs1); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char o_F5[8]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + printf("%02x ", o_F5[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "lui t5, %hi(i_F6)\n" + "addi t5, t5, %lo(i_F6)\n" + "fld ft6, 0(t5)\n" + ".insn 0x445372d3\n" // froundnx.h ft5, ft6 + "lui t5, %hi(o_F5)\n" + "addi t5, t5, %lo(o_F5)\n" + "fsd ft5, 0(t5)\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + + return 0; +} +``` +2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/2386 b/results/classifier/gemma3:12b/assembly/2386 new file mode 100644 index 000000000..baab48726 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2386 @@ -0,0 +1,44 @@ + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/241 b/results/classifier/gemma3:12b/assembly/241 new file mode 100644 index 000000000..ae4b719b6 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/241 @@ -0,0 +1,2 @@ + +Please refactor linux-user/mips/cpu_loop.c diff --git a/results/classifier/gemma3:12b/assembly/2413 b/results/classifier/gemma3:12b/assembly/2413 new file mode 100644 index 000000000..97b903ce9 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2413 @@ -0,0 +1,34 @@ + +Use of TSTEQ/TSTNE has regressed the cdrom test when running a 32 bit build of qemu-system-x86_64 using TCG +Description of problem: +The test freezes, eventually timing out. The bisect was confused by other SEV related things so I had to whittle down the config to --disable-kvm. +Steps to reproduce: +1. '../../configure' '--disable-docs' '--disable-user' '--cross-prefix=i686-linux-gnu-' '--target-list=x86_64-softmmu' '--enable-debug' '--disable-kvm' +2. ninja +3. meson test -t 0.05 qtest-x86_64/cdrom-test V=1 +Additional information: +Bisect run pointed at: + +``` +commit 15957eb9efe2da67c796612cead95cba28ba9bda +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Fri Oct 27 05:57:31 2023 +0200 + + target/i386: use TSTEQ/TSTNE to test low bits + + When testing the sign bit or equality to zero of a partial register, it + is useful to use a single TSTEQ or TSTNE operation. It can also be used + to test the parity flag, using bit 0 of the population count. + + Do not do this for target_ulong-sized values however; the optimizer would + produce a comparison against zero anyway, and it avoids shifts by 64 + which are undefined behavior. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/translate.c | 28 ++++++++++++++++++++-------- + target/i386/tcg/emit.c.inc | 5 ++--- + 2 files changed, 22 insertions(+), 11 deletions(-) +bisect found first bad commit⏎ +``` diff --git a/results/classifier/gemma3:12b/assembly/2419 b/results/classifier/gemma3:12b/assembly/2419 new file mode 100644 index 000000000..90c425b4a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2419 @@ -0,0 +1,19 @@ + +ldapr_stlr_i instructions doesn't consider signed offset +Description of problem: +The format ldapr_stlr_i models the load acquire / store release immediate instructions. \ +These instructions has a bug in the sign extension calculation of the imm field. \ +imm should be defined as s9 instead of 9. + +@ldapr_stlr_i .. ...... .. . imm:9 .. rn:5 rt:5 &ldapr_stlr_i + +Should be changed to: + +@ldapr_stlr_i .. ...... .. . imm:s9 .. rn:5 rt:5 &ldapr_stlr_i +Steps to reproduce: +1. Run ARM target +2. Generate any ldapr_stlr_i instructions (for example: LDAPUR) +3. When the imm value is negative, the immediate calculation is done wrong. In case the calculation leads to an undefined location, QEMU will fail. +Additional information: +In trans_LDAPR_i (translate-a64.c), when imm field is negative, the value of a->imm will be 512-x instead of x. \ +I already fixed the issue by adding the s9 to the imm field. This made a call to sextend32 for imm instead of extend32 in the generated file build/libqemu-aarch64-softmmu.fa.p/decode-a64.c.inc diff --git a/results/classifier/gemma3:12b/assembly/2422 b/results/classifier/gemma3:12b/assembly/2422 new file mode 100644 index 000000000..b8141c734 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2422 @@ -0,0 +1,70 @@ + +`vill` not set after reserved `vsetvli` instruction usage +Description of problem: +The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code. + +Here is the quote from the spec: + +> When `rs1=x0` and `rd=x0`, the instruction operates as if the current +> vector length in `vl` is used as the AVL, and the resulting value is +> written to `vl`, but not to a destination register. This form can +> only be used when VLMAX and hence `vl` is not actually changed by the +> new SEW/LMUL ratio. Use of the instruction with a new SEW/LMUL ratio +> that would result in a change of VLMAX is reserved. +> Use of the instruction is also reserved if `vill` was 1 beforehand. +> Implementations may set `vill` in either case. + +Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand". +Steps to reproduce: +1. Create `test.c` +```C +#include <assert.h> + +/* Position of vill in vtype. */ + +#define VILL_BIT (__riscv_xlen - 1) + +/* Return true if vill is 1. */ + +int vill_set_p () +{ + __UINT64_TYPE__ vtype; + asm volatile ("csrr %0, vtype" : "=r"(vtype)); + + return (vtype >> VILL_BIT) & 1; +} + +/* Return true if vill is 0. */ + +int vill_clear_p () +{ + return !vill_set_p (); +} + +int main () +{ + int vl; + + assert (vill_clear_p ()); + + /* Valid: vl = VLMAX. */ + asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl)); + assert (vill_clear_p ()); + + /* Valid: vl and VLMAX not changed. */ + asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n"); + assert (vill_clear_p ()); + + /* Reserved: Reduce VLMAX. */ + asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n"); + assert (vill_set_p ()); + + return 0; +} +``` +2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d` +3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test` +4. The final assertion fails because executing the reserved `vsetvli` did not set `vill` +``` +assertion "vill_set_p ()" failed: file "test.c", line 40, function: main +``` diff --git a/results/classifier/gemma3:12b/assembly/2438 b/results/classifier/gemma3:12b/assembly/2438 new file mode 100644 index 000000000..b80bd11e1 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2438 @@ -0,0 +1,2 @@ + +QEMU needs compat tweak to build against upstream capstone 6 diff --git a/results/classifier/gemma3:12b/assembly/2457 b/results/classifier/gemma3:12b/assembly/2457 new file mode 100644 index 000000000..c4f3f7b3b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2457 @@ -0,0 +1,2 @@ + +Building plugin sources doesn't produce any output to 'make' diff --git a/results/classifier/gemma3:12b/assembly/2487 b/results/classifier/gemma3:12b/assembly/2487 new file mode 100644 index 000000000..0dce70b30 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2487 @@ -0,0 +1,69 @@ + +qemu-x86_64: qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Description of problem: +Using this basic test file: + +```c +int +main (void) +{ + return 0; +} +``` + +compiled into a static executable using an x86_64 toolchain (glibc or musl both tested), + +``` +gwyn ~/qemu-bug # file test1 +test1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped + +gwyn ~/qemu-bug # file test2 +test2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=276dc49ee7cbd3b760e24761bf9fb9e1cc4b4349, for GNU/Linux 3.2.0, not stripped +``` + +Using QEMU from 15957eb9efe2da67c796612cead95cba28ba9bda or newer: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 --version +qemu-x86_64 version 9.0.50 (v9.0.0-521-g15957eb9ef-dirty) +Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers +``` + +QEMU crashes: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 ./test2 +** +ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Bail out! ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Aborted +``` +Steps to reproduce: +1. Build QEMU user for ppc64 (may affect other hosts) using commit 15957eb9efe2da67c796612cead95cba28ba9bda or newer. +2. Run any simple x86_64 executable. +3. Observe the crash. +Additional information: +Bisected to here: + +``` +commit 15957eb9efe2da67c796612cead95cba28ba9bda +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Fri Oct 27 05:57:31 2023 +0200 + + target/i386: use TSTEQ/TSTNE to test low bits + + When testing the sign bit or equality to zero of a partial register, it + is useful to use a single TSTEQ or TSTNE operation. It can also be used + to test the parity flag, using bit 0 of the population count. + + Do not do this for target_ulong-sized values however; the optimizer would + produce a comparison against zero anyway, and it avoids shifts by 64 + which are undefined behavior. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/emit.c.inc | 5 ++--- + target/i386/tcg/translate.c | 28 ++++++++++++++++++++-------- + 2 files changed, 22 insertions(+), 11 deletions(-) +``` diff --git a/results/classifier/gemma3:12b/assembly/2495 b/results/classifier/gemma3:12b/assembly/2495 new file mode 100644 index 000000000..8dc2ac764 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2495 @@ -0,0 +1,73 @@ + +A bug in x86-64 MMX instructions +Description of problem: +It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG. + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x270 + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f84f82ec143 +``` + +However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to: + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f98e82ec143 +``` + +I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs. + +It seems this bug looks similar to #2474. +Steps to reproduce: +1. Write `test.c` +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +uint8_t o_R8[8]; + +void __attribute__ ((noinline)) show_state() { + printf("R8: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_R8[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".intel_syntax noprefix\n" + "mov r8, qword ptr [rip + i_R8]\n" + "movq mm0, qword ptr [rip + i_MM0]\n" + ".byte 0x4f, 0x0f, 0x7e, 0xc0\n" + "mov qword ptr [rip + o_R8], r8\n" + ".att_syntax\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin` +3. Run QEMU using this command: `qemu-x86_64 ./test.bin` +4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/2569 b/results/classifier/gemma3:12b/assembly/2569 new file mode 100644 index 000000000..65fda03da --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2569 @@ -0,0 +1,6 @@ + +The alpha target doesn't support tcg plugin register tracking due to missing XML +Description of problem: +There is no register tracking because we build our register list based on XML and there was no XML for alpha because its so old. We could synthesise one to cover the register to fix this. +Steps to reproduce: +1. ./qemu-alpha -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=\* ./tests/tcg/alpha-linux-user/hello-alpha diff --git a/results/classifier/gemma3:12b/assembly/2595 b/results/classifier/gemma3:12b/assembly/2595 new file mode 100644 index 000000000..63c239416 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2595 @@ -0,0 +1,136 @@ + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include <stdio.h> + #include <arm_sve.h> + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/gemma3:12b/assembly/2599 b/results/classifier/gemma3:12b/assembly/2599 new file mode 100644 index 000000000..819072093 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2599 @@ -0,0 +1,2 @@ + +[x86] RET imm16 not align with native machine diff --git a/results/classifier/gemma3:12b/assembly/2606 b/results/classifier/gemma3:12b/assembly/2606 new file mode 100644 index 000000000..18498623d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2606 @@ -0,0 +1,199 @@ + +PowerPC host code is broken on Darwin +Description of problem: +Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI. +Steps to reproduce: +1. Run the build of qemu on Darwin ppc, see it fail. +Additional information: +This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes): +``` +--- common-user/host/ppc/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc/safe-syscall.inc.S 2023-08-18 18:08:15.000000000 +0800 +@@ -25,17 +25,11 @@ + # else + # error "Unknown ABI" + # endif +-#endif +- +-#ifndef _CALL_SYSV +-# error "Unsupported ABI" + #endif + +- + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -47,11 +41,8 @@ + * arguments being syscall arguments (also 'long'). + */ + safe_syscall_base: +- .cfi_startproc +- stwu 1, -8(1) +- .cfi_def_cfa_offset 8 +- stw 30, 4(1) +- .cfi_offset 30, -4 ++ stwu r1, -8(r1) ++ stw r30, 4(r1) + + /* + * We enter with r3 == &signal_pending +@@ -64,14 +55,14 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- mr 30, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ mr r30, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* + * This next sequence of code works in conjunction with the +@@ -83,25 +74,22 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(30) +- cmpwi 0, 12, 0 ++ lwz r12, 0(r30) ++ cmpwi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- lwz 30, 4(1) /* restore r30 */ +- addi 1, 1, 8 /* restore stack */ +- .cfi_restore 30 +- .cfi_def_cfa_offset 0 ++ lwz r30, 4(r1) /* restore r30 */ ++ addi r1, r1, 8 /* restore stack */ ++ + bnslr+ /* return on success */ + b safe_syscall_set_errno_tail + + /* code path when we didn't execute the syscall */ +-2: lwz 30, 4(1) +- addi 1, 1, 8 +- addi 3, 0, QEMU_ERESTARTSYS ++2: lwz r30, 4(r1) ++ addi r1, r1, 8 ++ addi r3, 0, QEMU_ERESTARTSYS + b safe_syscall_set_errno_tail + +- .cfi_endproc +- + .size safe_syscall_base, .-safe_syscall_base + + +--- common-user/host/ppc64/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc64/safe-syscall.inc.S 2022-05-31 13:23:21.000000000 +0800 +@@ -13,7 +13,6 @@ + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -23,19 +22,10 @@ + * second one the system call number (as a 'long'), and all further + * arguments being syscall arguments (also 'long'). + */ +-#if _CALL_ELF == 2 +-safe_syscall_base: +- .cfi_startproc +- .localentry safe_syscall_base,0 +-#else +- .section ".opd","aw" ++ + .align 3 + safe_syscall_base: +- .quad .L.safe_syscall_base,.TOC.@tocbase,0 +- .previous +-.L.safe_syscall_base: +- .cfi_startproc +-#endif ++ + /* We enter with r3 == &signal_pending + * r4 == syscall number + * r5 ... r10 == syscall arguments +@@ -46,16 +36,15 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- std 14, 16(1) /* Preserve r14 in SP+16 */ +- .cfi_offset 14, 16 +- mr 14, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ std r14, 16(r1) /* Preserve r14 in SP+16 */ ++ mr r14, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* This next sequence of code works in conjunction with the + * rewind_if_safe_syscall_function(). If a signal is taken +@@ -66,29 +55,20 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(14) +- cmpwi 0, 12, 0 ++ ld r12, 0(r14) ++ cmpdi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- ld 14, 16(1) /* restore r14 */ ++ ld r14, 16(r1) /* restore r14 */ + bso- 1f + blr + + /* code path when we didn't execute the syscall */ +-2: ld 14, 16(1) /* restore r14 */ +- addi 3, 0, QEMU_ERESTARTSYS ++2: ld r14, 16(r1) /* restore r14 */ ++ addi r3, 0, QEMU_ERESTARTSYS + + /* code path setting errno */ + 1: b safe_syscall_set_errno_tail + nop /* per abi, for the linker to modify */ +- +- .cfi_endproc +- +-#if _CALL_ELF == 2 +- .size safe_syscall_base, .-safe_syscall_base +-#else +- .size safe_syscall_base, .-.L.safe_syscall_base +- .size .L.safe_syscall_base, .-.L.safe_syscall_base +-#endif +``` +(Obviously, it is not made in a portable way – that was not needed at the time.) + +Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance. diff --git a/results/classifier/gemma3:12b/assembly/2613 b/results/classifier/gemma3:12b/assembly/2613 new file mode 100644 index 000000000..a86fb4b39 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2613 @@ -0,0 +1,2 @@ + +I was trying to build QEMU from source(noble) using debian commands in ubuntu24.04 derived docker and I got this error: cc1: error: ‘-fcf-protection’ is not compatible with this target diff --git a/results/classifier/gemma3:12b/assembly/2627 b/results/classifier/gemma3:12b/assembly/2627 new file mode 100644 index 000000000..3e18305e4 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2627 @@ -0,0 +1,2 @@ + +Possible incorrect exception order in RISC-V diff --git a/results/classifier/gemma3:12b/assembly/2696 b/results/classifier/gemma3:12b/assembly/2696 new file mode 100644 index 000000000..f77cb1659 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2696 @@ -0,0 +1,13 @@ + +qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction +Description of problem: +``` +❯ cat start.s +.globl _start +_start: .word 0 +❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld +❯ qemu-hexagon ./a.out +** +ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +``` diff --git a/results/classifier/gemma3:12b/assembly/2711 b/results/classifier/gemma3:12b/assembly/2711 new file mode 100644 index 000000000..e893132b1 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2711 @@ -0,0 +1,2 @@ + +TSTEQ lowering and optimization bug diff --git a/results/classifier/gemma3:12b/assembly/2730 b/results/classifier/gemma3:12b/assembly/2730 new file mode 100644 index 000000000..5947ac58a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2730 @@ -0,0 +1,11 @@ + +riscv Calculation error！ +Steps to reproduce: +The following command will produce an error output + +```asm + lui s0, 0x80000 + lw a1, -48(s0) +``` +The value of a1 becomes 0xffffffff + diff --git a/results/classifier/gemma3:12b/assembly/2802 b/results/classifier/gemma3:12b/assembly/2802 new file mode 100644 index 000000000..d6f7e3981 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2802 @@ -0,0 +1,27 @@ + +Sparc: fdtox/fqtox instructions incorrectly select destination register +Description of problem: +This bug report is mostly for informational purposes as I will be posting a fix for the bug. + +The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. +Steps to reproduce: +1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) +2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` +3. Run the test program using `qemu-sparc64-static ./test_program` +4. Expected output is 60. Prints 0 instead. +Additional information: +Test program to test the issue: + +```c +#include <stdio.h> + +int main(int argc, char** argv) { + long long truncated = 0; + __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); + __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); + printf("%lld\n", truncated); + return 0; +} +``` + +The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/results/classifier/gemma3:12b/assembly/2870 b/results/classifier/gemma3:12b/assembly/2870 new file mode 100644 index 000000000..29fe1cfc0 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2870 @@ -0,0 +1,2 @@ + +How to Create BE32-Type Instruction Emulation diff --git a/results/classifier/gemma3:12b/assembly/2871 b/results/classifier/gemma3:12b/assembly/2871 new file mode 100644 index 000000000..3ab2800a0 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2871 @@ -0,0 +1,2 @@ + +loongarch64: unknown register name 'f0' in asm diff --git a/results/classifier/gemma3:12b/assembly/2970 b/results/classifier/gemma3:12b/assembly/2970 new file mode 100644 index 000000000..fb1a8eaee --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2970 @@ -0,0 +1,2 @@ + +qemu version 10.0.0 fails to build with clang-21 (current trunk) diff --git a/results/classifier/gemma3:12b/assembly/2972 b/results/classifier/gemma3:12b/assembly/2972 new file mode 100644 index 000000000..e11501bbe --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/2972 @@ -0,0 +1,638 @@ + +loongarch64 inconsistencies between hardware and qemu due too lenient decoding of floating point comparisons +Description of problem: +(Related to #2971 ) + +Lenient instruction decoding of floating point comparisons leads to instructions that do not exist on hardware (Loongson 3A5000). + +The decoding of floating point compare instruction allows for instructions with illegal fcmp modes. + +The following are affected (`target/loongarch/insns.decode`): + +``` +vfcmp_cond_s 0000 11000101 ..... ..... ..... ..... @vvv_fcond +vfcmp_cond_d 0000 11000110 ..... ..... ..... ..... @vvv_fcond +xvfcmp_cond_s 0000 11001001 ..... ..... ..... ..... @vvv_fcond +xvfcmp_cond_d 0000 11001010 ..... ..... ..... ..... @vvv_fcond +fcmp_cond_s 0000 11000001 ..... ..... ..... 00 ... @cff_fcond +fcmp_cond_d 0000 11000010 ..... ..... ..... 00 ... @cff_fcond +``` + +The `get_fcmp_flags` function in `target/loongarch/tcg/insn_trans/trans_fcmp.c.inc` allows decoding all possible 4-bit condition values even though some are invalid on hardware (Loongson 3A5000): + +<details><summary>qemu-loongarch64-static</summary> + +``` + --- fcond = 0b0 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b100 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b101 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b110 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b111 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1000 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1001 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1010 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1011 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1100 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1101 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1110 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1111 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10000 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10001 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10010 (LT | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10011 (LT | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10100 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10101 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10110 (LT | EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10111 (LT | EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11000 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11001 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11010 (LT | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11011 (LT | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11100 (EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11101 (EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11110 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11111 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True +``` + +</details> + + +<details><summary>Loongson 3A5000</summary> + +``` + --- fcond = 0b0 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b100 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b101 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b110 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b111 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1000 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1001 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1010 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1011 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1100 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1101 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1110 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1111 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10000 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10001 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10010 (LT | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b10011 (LT | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b10100 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10101 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10110 (LT | EQ | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b10111 (LT | EQ | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11000 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11001 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11010 (LT | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11011 (LT | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11100 (EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11101 (EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11110 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11111 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False +``` + +</details> +Steps to reproduce: +1. compile the `test_instr_valid` test program for loongarch64 (see additional information). +2. run the `check_defined.py` python script to print out information about defined instructions. +3. All tested fcmp instructions are defined when run using qemu, but some are invalid (SIGILL) on actual hardware. +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_instr_valid` source code: + +```C +#include <signal.h> +#include <errno.h> +#include <stdio.h> +#include <stddef.h> +#include <stdint.h> +#include <stdlib.h> +#include <sys/mman.h> + +#define PAGE_SIZE 0x4000 + +#define ret 0x4c000020 + +typedef void (*instr_fun)(void); + +static __attribute__((aligned(PAGE_SIZE))) uint32_t code[PAGE_SIZE / sizeof(uint32_t)]; + +void handler(int signo, siginfo_t *info, void *context) { + printf("False"); + exit(0); +} + +int main(int argc, char** argv) { + struct sigaction act = { 0 }; + act.sa_flags = SA_SIGINFO | SA_ONSTACK; + act.sa_sigaction = &handler; + sigaction(SIGILL, &act, NULL); + uint32_t instr = (uint32_t)strtoull(argv[1], NULL, 0); + code[0] = instr; + code[1] = ret; + mprotect(code, sizeof(code), PROT_READ | PROT_EXEC); + instr_fun f = (instr_fun)(void*)code; + f(); + printf("True"); + exit(0); +} +``` + +`check_defined.py`: + +```py +import subprocess + +CMD = ["qemu-loongarch64-static", "./test_instr_valid"] # remove "qemu-loongarch64-static" when running without emulation + +def is_defined(instr): + try: + return eval(subprocess.check_output(CMD + [hex(instr)]).decode()) + except: + return False + +bases = [ + ("vfcmp_cond_s ", 0b00001100010100000000000000000000), # vfcmp_cond_s 0000 11000101 ..... ..... ..... ..... @vvv_fcond + ("vfcmp_cond_d ", 0b00001100011000000000000000000000), # vfcmp_cond_d 0000 11000110 ..... ..... ..... ..... @vvv_fcond + ("xvfcmp_cond_s", 0b00001100100100000000000000000000), # xvfcmp_cond_s 0000 11001001 ..... ..... ..... ..... @vvv_fcond + ("xvfcmp_cond_d", 0b00001100101000000000000000000000), # xvfcmp_cond_d 0000 11001010 ..... ..... ..... ..... @vvv_fcond +] + +bases_2 = [ + ("fcmp_cond_s ", 0b00001100000100000000000000000000), # fcmp_cond_s 0000 11000001 ..... ..... ..... 00 ... @cff_fcond + ("fcmp_cond_d ", 0b00001100001000000000000000000000), # fcmp_cond_d 0000 11000010 ..... ..... ..... 00 ... @cff_fcond +] + +def format_fcond(val): + x = ["LT", "EQ", "UN", "LT | GT"] + return " | ".join(x[i] for i in range(4) if (val >> 1) & (1 << i)) + +fcond_shift = 15 + +# use r1, r2, r3 for vector instructions +reg_mask = 0b000110001000001 + +# use c0, r1, r2 for normal instructions +reg_mask_2 = 0b000100000100000 + +for fcond in range(1 << 5): + print(f" --- fcond = {bin(fcond)} ({format_fcond(fcond)}) --- ") + for name, mask in bases: + print(name, is_defined(mask | reg_mask | (fcond << fcond_shift))) + for name, mask in bases_2: + print(name, is_defined(mask | reg_mask_2 | (fcond << fcond_shift))) + print("") +``` diff --git a/results/classifier/gemma3:12b/assembly/364 b/results/classifier/gemma3:12b/assembly/364 new file mode 100644 index 000000000..ef2b733f6 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/364 @@ -0,0 +1,2 @@ + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/gemma3:12b/assembly/372 b/results/classifier/gemma3:12b/assembly/372 new file mode 100644 index 000000000..e1fc27269 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/372 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the TCG / CPU subsystem diff --git a/results/classifier/gemma3:12b/assembly/422 b/results/classifier/gemma3:12b/assembly/422 new file mode 100644 index 000000000..2586106ce --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/422 @@ -0,0 +1,2 @@ + +Unable to execute MIPS MSA code due to illegal instruction diff --git a/results/classifier/gemma3:12b/assembly/47 b/results/classifier/gemma3:12b/assembly/47 new file mode 100644 index 000000000..a6fdfa970 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/47 @@ -0,0 +1,2 @@ + +A typo in target/riscv/insn32-64.decode diff --git a/results/classifier/gemma3:12b/assembly/480 b/results/classifier/gemma3:12b/assembly/480 new file mode 100644 index 000000000..751a7d5cf --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/480 @@ -0,0 +1,2 @@ + +Supported ARMv8.? Opcodes diff --git a/results/classifier/gemma3:12b/assembly/491 b/results/classifier/gemma3:12b/assembly/491 new file mode 100644 index 000000000..1eb695557 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/491 @@ -0,0 +1,2 @@ + +There is a code error here diff --git a/results/classifier/gemma3:12b/assembly/494 b/results/classifier/gemma3:12b/assembly/494 new file mode 100644 index 000000000..6c08c0b9b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/494 @@ -0,0 +1,2 @@ + +cmake crashes on qemu-alpha-user with Illegal Instruction diff --git a/results/classifier/gemma3:12b/assembly/509 b/results/classifier/gemma3:12b/assembly/509 new file mode 100644 index 000000000..9ba90866f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/509 @@ -0,0 +1,2 @@ + +Atomic test-and-set instruction does not work on qemu-user diff --git a/results/classifier/gemma3:12b/assembly/571 b/results/classifier/gemma3:12b/assembly/571 new file mode 100644 index 000000000..c2e632b66 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/571 @@ -0,0 +1,2 @@ + +maybe-uninitialized warning in mips cpu_loop() diff --git a/results/classifier/gemma3:12b/assembly/613 b/results/classifier/gemma3:12b/assembly/613 new file mode 100644 index 000000000..84186493a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/613 @@ -0,0 +1,2 @@ + +ARM cortex-m55 LOB instructions make QEMU crash diff --git a/results/classifier/gemma3:12b/assembly/63 b/results/classifier/gemma3:12b/assembly/63 new file mode 100644 index 000000000..b94475a2b --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/63 @@ -0,0 +1,2 @@ + +Illegal delay slot code causes abort on mips64 diff --git a/results/classifier/gemma3:12b/assembly/683 b/results/classifier/gemma3:12b/assembly/683 new file mode 100644 index 000000000..5638497df --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/683 @@ -0,0 +1,2 @@ + +certain programs make QEMU crash with "tcg fatal error" diff --git a/results/classifier/gemma3:12b/assembly/695 b/results/classifier/gemma3:12b/assembly/695 new file mode 100644 index 000000000..aa0da3e5e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/695 @@ -0,0 +1,2 @@ + +MIPS: nanomips p32 ABI not supported diff --git a/results/classifier/gemma3:12b/assembly/710 b/results/classifier/gemma3:12b/assembly/710 new file mode 100644 index 000000000..b4fee098f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/710 @@ -0,0 +1,2 @@ + +maybe-uninitialized warning building target/m68k/ with -O3 diff --git a/results/classifier/gemma3:12b/assembly/713 b/results/classifier/gemma3:12b/assembly/713 new file mode 100644 index 000000000..dd9a62496 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/713 @@ -0,0 +1,2 @@ + +Missing safe-syscall.inc.S for mips diff --git a/results/classifier/gemma3:12b/assembly/788886 b/results/classifier/gemma3:12b/assembly/788886 new file mode 100644 index 000000000..bc475a40e --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/788886 @@ -0,0 +1,9 @@ + +Crash with -m32 and gcc-4.2 on Mac OS X 64bit + +For building 32bit Qemu on Mac OS X 10.6.7 , i configure with --extra-cflags=-m32 --extra-ldflags=-m32. make with gcc-4.2 then crashes with: + + GEN qemu-options.def + CC qemu-nbd.o +gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags +make: *** [qemu-nbd.o] Error 1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/799 b/results/classifier/gemma3:12b/assembly/799 new file mode 100644 index 000000000..7ccec1701 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/799 @@ -0,0 +1,48 @@ + +TCG Optimizer crashes on AArch64 SVE2 instruction +Description of problem: +QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: +``` +Unrecognized operation 145 in do_constant_folding. +../tcg/optimize.c:458: tcg fatal error +``` +Steps to reproduce: +1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) +```asm +.org 0x0 +entry: + mrs x1, cptr_el3 + orr x9, x1, #0x100 + msr cptr_el3, x9 + + msr cptr_el2, xzr + + mov x1, #0x3 + mrs x9, cpacr_el1 + bfi x9, x1, #16, #2 + bfi x9, x1, #20, #2 + msr cpacr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el2, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el3, x9 + + uqxtnt z11.s, z22.d +``` +2. Execute it using the command line given above. +Additional information: +I tested latest master as well, and the problem persists. diff --git a/results/classifier/gemma3:12b/assembly/863 b/results/classifier/gemma3:12b/assembly/863 new file mode 100644 index 000000000..24c736c4c --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/863 @@ -0,0 +1,55 @@ + +contrib/plugins/howvec.c for ARM64 under constrained +Description of problem: +Consider the static InsnClassExecCount aarch64_insn_classes array in contrib/plugins/howvec.c There are 5 entries which will never be discovered, and so count as 0; see the dump below. + +I did not figure out which of prior rows in the table was over-eagerly getting instructions intended for the subsequent counted-as-0 row. + +``` + udef aka UDEF 65536 + sve aka SVE 268435456 + res aka Reserved 268369920 + pcrel aka PCrel addr 134217728 + asit aka Add/Sub (imm,tags) 67108864 + asi aka Add/Sub (imm) 67108864 + logi aka Logical (imm) 67108864 + movwi aka Move Wide (imm) 67108864 + bitf aka Bitfield 67108864 + extr aka Extract 67108864 + dpri aka Data Proc Imm 0 + cndb aka Cond Branch (imm) 33554432 + excp aka Exception Gen 16777216 + nop aka NOP 1 + hint aka Hints 4095 + barr aka Barriers 4096 + psta aka PSTATE 32768 + sins aka System Insn 1048576 + sreg aka System Reg 2097152 + breg aka Branch (reg) 33554432 + bimm aka Branch (imm) 134217728 + cmpb aka Cmp & Branch 67108864 + tstb aka Tst & Branch 67108864 + branch aka Branches 181362688 + advlsm aka AdvSimd ldstmult 262144 + advlsmp aka AdvSimd ldstmult++ 4194304 + advlss aka AdvSimd ldst 524288 + advlssp aka AdvSimd ldst++ 16777216 + ldstx aka ldst excl 67108864 + prfm aka Prefetch 16777216 + ldlit aka Load Reg (lit) 251658240 + ldstnap aka ldst noalloc pair 67108864 + ldstp aka ldst pair 469762048 + ldstr aka ldst reg 0 + atomic aka Atomic ldst 0 + ldstro aka ldst reg (reg off) 0 + ldstpa aka ldst reg (pac) 0 + ldsti aka ldst reg (imm) 134217728 + ldst aka Loads & Stores 313786368 + dprr aka Data Proc Reg 402653184 + fpsimd aka Scalar FP 402653183 + unclas aka Unclassified 536870912 +``` +Steps to reproduce: +1. Write a simple wrapper program; iterate and search through all 2**32 insns, dump the array +2. +3. diff --git a/results/classifier/gemma3:12b/assembly/881637 b/results/classifier/gemma3:12b/assembly/881637 new file mode 100644 index 000000000..c85651bee --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/881637 @@ -0,0 +1,15 @@ + +QEMU fails to build on OpenBSD/hppa + +Trying to build previous QEMU releases as well as git code fails on OpenBSD/hppa... + +cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c +/tmp//ccvNbj1U.s: Assembler messages: +/tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776). +/tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096). +/tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136). +/tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612). +/tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260). +/tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784). +/tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636). +/tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/889053 b/results/classifier/gemma3:12b/assembly/889053 new file mode 100644 index 000000000..04b81298a --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/889053 @@ -0,0 +1,16 @@ + +x86: FPU_MAX, FPU_MIN incorrect + +Dear All, + +Bug was found in qemu.git. +Now (0.15, 1.0) all fpu is softfpu. +See target-i386/ops_sse.h: +#define FPU_MIN(size, a, b) (a) < (b) ? (a) : (b) +#define FPU_MAX(size, a, b) (a) > (b) ? (a) : (b) +It is incorrect now, becouse float64 (or 32) is (typedef) uint64_t (or 32). +And if we have signed operands we get error... + +There is a test with this error (spec shinx3 test data, results diffs on machine and qemu (linux)) and fixed patch. See attach. + +Daniil. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/assembly/890 b/results/classifier/gemma3:12b/assembly/890 new file mode 100644 index 000000000..6544b5f7d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/890 @@ -0,0 +1,2 @@ + +Misinterpretation of arm neon invalid insn diff --git a/results/classifier/gemma3:12b/assembly/947 b/results/classifier/gemma3:12b/assembly/947 new file mode 100644 index 000000000..5bfad3a1d --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/947 @@ -0,0 +1,14 @@ + +TCG AARCH64 Segmentation fault when helper function is called +Description of problem: +Segmentation fault in the TCG thread. +The issue occurs in the generated code when branching to (helper)lookup_tb_ptr (see op longs). +It seems that the generated instruction don't load the upper32 of the address of lookup_tb_ptr in the register before branching to it. According to LLDB, the program tries to access 0x1cffe060 while the right address 0x7ff71cffe060 (see debugger logs). +Additional information: +The issue seems to be located at https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/aarch64/tcg-target.c.inc#L1091 +`t2 = t1 & ~(0xffffUL << s1);`. +The fix would be `t2 = t1 & ~(0xffffULL << s1);` + + +[lldb.log](/uploads/6a1d57eaecae4a375c6ada7384489876/lldb.log) +[qemu_segmentation.log](/uploads/e3c2d6d42291ff7d1ff8d37341e3da1d/qemu_segmentation.log) diff --git a/results/classifier/gemma3:12b/assembly/953 b/results/classifier/gemma3:12b/assembly/953 new file mode 100644 index 000000000..fef559a8c --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/953 @@ -0,0 +1,2 @@ + +qemu-system-aarch64 asserts trying to execute STXP on hosts without HAVE_CMPXCHG128 diff --git a/results/classifier/gemma3:12b/assembly/979 b/results/classifier/gemma3:12b/assembly/979 new file mode 100644 index 000000000..8a7099c7f --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/979 @@ -0,0 +1,8 @@ + +s390x floating point conversion functions broken +Description of problem: +While collecting additional reference files for float_convs (and float_convd) I noticed that the s390x handling of some cases is broken. See diff for details: + +``` + diff -y tests/tcg/s390x-linux-user/float_convs.out ../../tests/tcg/s390x/float_convs.ref +# diff --git a/results/classifier/gemma3:12b/assembly/984 b/results/classifier/gemma3:12b/assembly/984 new file mode 100644 index 000000000..ff537eaca --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/984 @@ -0,0 +1,24 @@ + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 diff --git a/results/classifier/gemma3:12b/assembly/996798 b/results/classifier/gemma3:12b/assembly/996798 new file mode 100644 index 000000000..ced953bb0 --- /dev/null +++ b/results/classifier/gemma3:12b/assembly/996798 @@ -0,0 +1,12 @@ + +Incorrect order of task switching + +In Intel specifications (http://download.intel.com/design/processor/manuals/253668.pdf 7.3), we can see: + + 8. Saves the state of the current (old) task in the current task’s TSS. + +… + + 11. Loads the task register with the segment selector and descriptor for the new task's TSS. + +But, in QEMU code (https://raw.github.com/qemu/QEMU/v1.0/target-i386/op_helper.c :375), the order is reversed: TSS registers & segments loads BEFORE save old task state. \ No newline at end of file |