From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- results/classifier/gemma3:12b/assembly/1028 | 35 ++ results/classifier/gemma3:12b/assembly/1093691 | 33 ++ results/classifier/gemma3:12b/assembly/1096 | 2 + results/classifier/gemma3:12b/assembly/1104 | 2 + results/classifier/gemma3:12b/assembly/1119 | 16 + results/classifier/gemma3:12b/assembly/1154 | 2 + results/classifier/gemma3:12b/assembly/1233 | 2 + results/classifier/gemma3:12b/assembly/1245543 | 24 + results/classifier/gemma3:12b/assembly/1248 | 12 + results/classifier/gemma3:12b/assembly/1251 | 16 + results/classifier/gemma3:12b/assembly/1267955 | 43 ++ results/classifier/gemma3:12b/assembly/1308381 | 15 + results/classifier/gemma3:12b/assembly/1319 | 14 + results/classifier/gemma3:12b/assembly/132 | 2 + results/classifier/gemma3:12b/assembly/1350 | 90 ++++ results/classifier/gemma3:12b/assembly/1350435 | 17 + results/classifier/gemma3:12b/assembly/1357175 | 17 + results/classifier/gemma3:12b/assembly/1371 | 20 + results/classifier/gemma3:12b/assembly/1372 | 21 + results/classifier/gemma3:12b/assembly/1402 | 60 +++ results/classifier/gemma3:12b/assembly/1414293 | 6 + results/classifier/gemma3:12b/assembly/1422 | 16 + results/classifier/gemma3:12b/assembly/1435 | 17 + results/classifier/gemma3:12b/assembly/1437811 | 8 + results/classifier/gemma3:12b/assembly/1452 | 2 + results/classifier/gemma3:12b/assembly/1469342 | 4 + results/classifier/gemma3:12b/assembly/1486911 | 47 ++ results/classifier/gemma3:12b/assembly/1511 | 2 + results/classifier/gemma3:12b/assembly/1514 | 2 + results/classifier/gemma3:12b/assembly/1533141 | 16 + results/classifier/gemma3:12b/assembly/1536 | 17 + results/classifier/gemma3:12b/assembly/1550503 | 14 + results/classifier/gemma3:12b/assembly/1581 | 15 + results/classifier/gemma3:12b/assembly/1590336 | 16 + results/classifier/gemma3:12b/assembly/1591611 | 24 + results/classifier/gemma3:12b/assembly/1592 | 17 + results/classifier/gemma3:12b/assembly/1612 | 52 ++ results/classifier/gemma3:12b/assembly/1619 | 2 + results/classifier/gemma3:12b/assembly/1620 | 95 ++++ results/classifier/gemma3:12b/assembly/1631625 | 16 + results/classifier/gemma3:12b/assembly/164 | 2 + results/classifier/gemma3:12b/assembly/1641637 | 714 +++++++++++++++++++++++++ results/classifier/gemma3:12b/assembly/1642 | 23 + results/classifier/gemma3:12b/assembly/1661 | 12 + results/classifier/gemma3:12b/assembly/1667 | 2 + results/classifier/gemma3:12b/assembly/1673 | 50 ++ results/classifier/gemma3:12b/assembly/1698 | 2 + results/classifier/gemma3:12b/assembly/1699 | 2 + results/classifier/gemma3:12b/assembly/1711828 | 4 + results/classifier/gemma3:12b/assembly/1714 | 28 + results/classifier/gemma3:12b/assembly/1721275 | 27 + results/classifier/gemma3:12b/assembly/1725267 | 32 ++ results/classifier/gemma3:12b/assembly/1737 | 50 ++ results/classifier/gemma3:12b/assembly/1750 | 2 + results/classifier/gemma3:12b/assembly/1751494 | 17 + results/classifier/gemma3:12b/assembly/1755479 | 26 + results/classifier/gemma3:12b/assembly/1781281 | 29 + results/classifier/gemma3:12b/assembly/1787002 | 20 + results/classifier/gemma3:12b/assembly/1793608 | 17 + results/classifier/gemma3:12b/assembly/1807675 | 31 ++ results/classifier/gemma3:12b/assembly/1815024 | 16 + results/classifier/gemma3:12b/assembly/1815423 | 65 +++ results/classifier/gemma3:12b/assembly/1832 | 2 + results/classifier/gemma3:12b/assembly/1832250 | 58 ++ results/classifier/gemma3:12b/assembly/1832422 | 10 + results/classifier/gemma3:12b/assembly/1833 | 85 +++ results/classifier/gemma3:12b/assembly/1834399 | 37 ++ results/classifier/gemma3:12b/assembly/1840 | 2 + results/classifier/gemma3:12b/assembly/1841990 | 39 ++ results/classifier/gemma3:12b/assembly/1847 | 2 + results/classifier/gemma3:12b/assembly/1847467 | 17 + results/classifier/gemma3:12b/assembly/1849879 | 11 + results/classifier/gemma3:12b/assembly/1856706 | 14 + results/classifier/gemma3:12b/assembly/1861946 | 214 ++++++++ results/classifier/gemma3:12b/assembly/1862167 | 4 + results/classifier/gemma3:12b/assembly/1879955 | 24 + results/classifier/gemma3:12b/assembly/1881004 | 51 ++ results/classifier/gemma3:12b/assembly/1883984 | 27 + results/classifier/gemma3:12b/assembly/1885718 | 10 + results/classifier/gemma3:12b/assembly/1909392 | 21 + results/classifier/gemma3:12b/assembly/1912065 | 33 ++ results/classifier/gemma3:12b/assembly/1912934 | 18 + results/classifier/gemma3:12b/assembly/1915327 | 35 ++ results/classifier/gemma3:12b/assembly/1916394 | 19 + results/classifier/gemma3:12b/assembly/1925512 | 19 + results/classifier/gemma3:12b/assembly/1926277 | 38 ++ results/classifier/gemma3:12b/assembly/1934 | 25 + results/classifier/gemma3:12b/assembly/1942 | 10 + results/classifier/gemma3:12b/assembly/1955 | 27 + results/classifier/gemma3:12b/assembly/1970 | 2 + results/classifier/gemma3:12b/assembly/2076 | 2 + results/classifier/gemma3:12b/assembly/2083 | 112 ++++ results/classifier/gemma3:12b/assembly/2106 | 56 ++ results/classifier/gemma3:12b/assembly/2136 | 36 ++ results/classifier/gemma3:12b/assembly/2175 | 39 ++ results/classifier/gemma3:12b/assembly/2203 | 2 + results/classifier/gemma3:12b/assembly/2222 | 2 + results/classifier/gemma3:12b/assembly/2236 | 2 + results/classifier/gemma3:12b/assembly/2302 | 26 + results/classifier/gemma3:12b/assembly/2317 | 39 ++ results/classifier/gemma3:12b/assembly/2320 | 2 + results/classifier/gemma3:12b/assembly/2336 | 24 + results/classifier/gemma3:12b/assembly/2371 | 53 ++ results/classifier/gemma3:12b/assembly/2386 | 44 ++ results/classifier/gemma3:12b/assembly/241 | 2 + results/classifier/gemma3:12b/assembly/2413 | 34 ++ results/classifier/gemma3:12b/assembly/2419 | 19 + results/classifier/gemma3:12b/assembly/2422 | 70 +++ results/classifier/gemma3:12b/assembly/2438 | 2 + results/classifier/gemma3:12b/assembly/2457 | 2 + results/classifier/gemma3:12b/assembly/2487 | 69 +++ results/classifier/gemma3:12b/assembly/2495 | 73 +++ results/classifier/gemma3:12b/assembly/2569 | 6 + results/classifier/gemma3:12b/assembly/2595 | 136 +++++ results/classifier/gemma3:12b/assembly/2599 | 2 + results/classifier/gemma3:12b/assembly/2606 | 199 +++++++ results/classifier/gemma3:12b/assembly/2613 | 2 + results/classifier/gemma3:12b/assembly/2627 | 2 + results/classifier/gemma3:12b/assembly/2696 | 13 + results/classifier/gemma3:12b/assembly/2711 | 2 + results/classifier/gemma3:12b/assembly/2730 | 11 + results/classifier/gemma3:12b/assembly/2802 | 27 + results/classifier/gemma3:12b/assembly/2870 | 2 + results/classifier/gemma3:12b/assembly/2871 | 2 + results/classifier/gemma3:12b/assembly/2970 | 2 + results/classifier/gemma3:12b/assembly/2972 | 638 ++++++++++++++++++++++ results/classifier/gemma3:12b/assembly/364 | 2 + results/classifier/gemma3:12b/assembly/372 | 2 + results/classifier/gemma3:12b/assembly/422 | 2 + results/classifier/gemma3:12b/assembly/47 | 2 + results/classifier/gemma3:12b/assembly/480 | 2 + results/classifier/gemma3:12b/assembly/491 | 2 + results/classifier/gemma3:12b/assembly/494 | 2 + results/classifier/gemma3:12b/assembly/509 | 2 + results/classifier/gemma3:12b/assembly/571 | 2 + results/classifier/gemma3:12b/assembly/613 | 2 + results/classifier/gemma3:12b/assembly/63 | 2 + results/classifier/gemma3:12b/assembly/683 | 2 + results/classifier/gemma3:12b/assembly/695 | 2 + results/classifier/gemma3:12b/assembly/710 | 2 + results/classifier/gemma3:12b/assembly/713 | 2 + results/classifier/gemma3:12b/assembly/788886 | 9 + results/classifier/gemma3:12b/assembly/799 | 48 ++ results/classifier/gemma3:12b/assembly/863 | 55 ++ results/classifier/gemma3:12b/assembly/881637 | 15 + results/classifier/gemma3:12b/assembly/889053 | 16 + results/classifier/gemma3:12b/assembly/890 | 2 + results/classifier/gemma3:12b/assembly/947 | 14 + results/classifier/gemma3:12b/assembly/953 | 2 + results/classifier/gemma3:12b/assembly/979 | 8 + results/classifier/gemma3:12b/assembly/984 | 24 + results/classifier/gemma3:12b/assembly/996798 | 12 + 152 files changed, 4845 insertions(+) create mode 100644 results/classifier/gemma3:12b/assembly/1028 create mode 100644 results/classifier/gemma3:12b/assembly/1093691 create mode 100644 results/classifier/gemma3:12b/assembly/1096 create mode 100644 results/classifier/gemma3:12b/assembly/1104 create mode 100644 results/classifier/gemma3:12b/assembly/1119 create mode 100644 results/classifier/gemma3:12b/assembly/1154 create mode 100644 results/classifier/gemma3:12b/assembly/1233 create mode 100644 results/classifier/gemma3:12b/assembly/1245543 create mode 100644 results/classifier/gemma3:12b/assembly/1248 create mode 100644 results/classifier/gemma3:12b/assembly/1251 create mode 100644 results/classifier/gemma3:12b/assembly/1267955 create mode 100644 results/classifier/gemma3:12b/assembly/1308381 create mode 100644 results/classifier/gemma3:12b/assembly/1319 create mode 100644 results/classifier/gemma3:12b/assembly/132 create mode 100644 results/classifier/gemma3:12b/assembly/1350 create mode 100644 results/classifier/gemma3:12b/assembly/1350435 create mode 100644 results/classifier/gemma3:12b/assembly/1357175 create mode 100644 results/classifier/gemma3:12b/assembly/1371 create mode 100644 results/classifier/gemma3:12b/assembly/1372 create mode 100644 results/classifier/gemma3:12b/assembly/1402 create mode 100644 results/classifier/gemma3:12b/assembly/1414293 create mode 100644 results/classifier/gemma3:12b/assembly/1422 create mode 100644 results/classifier/gemma3:12b/assembly/1435 create mode 100644 results/classifier/gemma3:12b/assembly/1437811 create mode 100644 results/classifier/gemma3:12b/assembly/1452 create mode 100644 results/classifier/gemma3:12b/assembly/1469342 create mode 100644 results/classifier/gemma3:12b/assembly/1486911 create mode 100644 results/classifier/gemma3:12b/assembly/1511 create mode 100644 results/classifier/gemma3:12b/assembly/1514 create mode 100644 results/classifier/gemma3:12b/assembly/1533141 create mode 100644 results/classifier/gemma3:12b/assembly/1536 create mode 100644 results/classifier/gemma3:12b/assembly/1550503 create mode 100644 results/classifier/gemma3:12b/assembly/1581 create mode 100644 results/classifier/gemma3:12b/assembly/1590336 create mode 100644 results/classifier/gemma3:12b/assembly/1591611 create mode 100644 results/classifier/gemma3:12b/assembly/1592 create mode 100644 results/classifier/gemma3:12b/assembly/1612 create mode 100644 results/classifier/gemma3:12b/assembly/1619 create mode 100644 results/classifier/gemma3:12b/assembly/1620 create mode 100644 results/classifier/gemma3:12b/assembly/1631625 create mode 100644 results/classifier/gemma3:12b/assembly/164 create mode 100644 results/classifier/gemma3:12b/assembly/1641637 create mode 100644 results/classifier/gemma3:12b/assembly/1642 create mode 100644 results/classifier/gemma3:12b/assembly/1661 create mode 100644 results/classifier/gemma3:12b/assembly/1667 create mode 100644 results/classifier/gemma3:12b/assembly/1673 create mode 100644 results/classifier/gemma3:12b/assembly/1698 create mode 100644 results/classifier/gemma3:12b/assembly/1699 create mode 100644 results/classifier/gemma3:12b/assembly/1711828 create mode 100644 results/classifier/gemma3:12b/assembly/1714 create mode 100644 results/classifier/gemma3:12b/assembly/1721275 create mode 100644 results/classifier/gemma3:12b/assembly/1725267 create mode 100644 results/classifier/gemma3:12b/assembly/1737 create mode 100644 results/classifier/gemma3:12b/assembly/1750 create mode 100644 results/classifier/gemma3:12b/assembly/1751494 create mode 100644 results/classifier/gemma3:12b/assembly/1755479 create mode 100644 results/classifier/gemma3:12b/assembly/1781281 create mode 100644 results/classifier/gemma3:12b/assembly/1787002 create mode 100644 results/classifier/gemma3:12b/assembly/1793608 create mode 100644 results/classifier/gemma3:12b/assembly/1807675 create mode 100644 results/classifier/gemma3:12b/assembly/1815024 create mode 100644 results/classifier/gemma3:12b/assembly/1815423 create mode 100644 results/classifier/gemma3:12b/assembly/1832 create mode 100644 results/classifier/gemma3:12b/assembly/1832250 create mode 100644 results/classifier/gemma3:12b/assembly/1832422 create mode 100644 results/classifier/gemma3:12b/assembly/1833 create mode 100644 results/classifier/gemma3:12b/assembly/1834399 create mode 100644 results/classifier/gemma3:12b/assembly/1840 create mode 100644 results/classifier/gemma3:12b/assembly/1841990 create mode 100644 results/classifier/gemma3:12b/assembly/1847 create mode 100644 results/classifier/gemma3:12b/assembly/1847467 create mode 100644 results/classifier/gemma3:12b/assembly/1849879 create mode 100644 results/classifier/gemma3:12b/assembly/1856706 create mode 100644 results/classifier/gemma3:12b/assembly/1861946 create mode 100644 results/classifier/gemma3:12b/assembly/1862167 create mode 100644 results/classifier/gemma3:12b/assembly/1879955 create mode 100644 results/classifier/gemma3:12b/assembly/1881004 create mode 100644 results/classifier/gemma3:12b/assembly/1883984 create mode 100644 results/classifier/gemma3:12b/assembly/1885718 create mode 100644 results/classifier/gemma3:12b/assembly/1909392 create mode 100644 results/classifier/gemma3:12b/assembly/1912065 create mode 100644 results/classifier/gemma3:12b/assembly/1912934 create mode 100644 results/classifier/gemma3:12b/assembly/1915327 create mode 100644 results/classifier/gemma3:12b/assembly/1916394 create mode 100644 results/classifier/gemma3:12b/assembly/1925512 create mode 100644 results/classifier/gemma3:12b/assembly/1926277 create mode 100644 results/classifier/gemma3:12b/assembly/1934 create mode 100644 results/classifier/gemma3:12b/assembly/1942 create mode 100644 results/classifier/gemma3:12b/assembly/1955 create mode 100644 results/classifier/gemma3:12b/assembly/1970 create mode 100644 results/classifier/gemma3:12b/assembly/2076 create mode 100644 results/classifier/gemma3:12b/assembly/2083 create mode 100644 results/classifier/gemma3:12b/assembly/2106 create mode 100644 results/classifier/gemma3:12b/assembly/2136 create mode 100644 results/classifier/gemma3:12b/assembly/2175 create mode 100644 results/classifier/gemma3:12b/assembly/2203 create mode 100644 results/classifier/gemma3:12b/assembly/2222 create mode 100644 results/classifier/gemma3:12b/assembly/2236 create mode 100644 results/classifier/gemma3:12b/assembly/2302 create mode 100644 results/classifier/gemma3:12b/assembly/2317 create mode 100644 results/classifier/gemma3:12b/assembly/2320 create mode 100644 results/classifier/gemma3:12b/assembly/2336 create mode 100644 results/classifier/gemma3:12b/assembly/2371 create mode 100644 results/classifier/gemma3:12b/assembly/2386 create mode 100644 results/classifier/gemma3:12b/assembly/241 create mode 100644 results/classifier/gemma3:12b/assembly/2413 create mode 100644 results/classifier/gemma3:12b/assembly/2419 create mode 100644 results/classifier/gemma3:12b/assembly/2422 create mode 100644 results/classifier/gemma3:12b/assembly/2438 create mode 100644 results/classifier/gemma3:12b/assembly/2457 create mode 100644 results/classifier/gemma3:12b/assembly/2487 create mode 100644 results/classifier/gemma3:12b/assembly/2495 create mode 100644 results/classifier/gemma3:12b/assembly/2569 create mode 100644 results/classifier/gemma3:12b/assembly/2595 create mode 100644 results/classifier/gemma3:12b/assembly/2599 create mode 100644 results/classifier/gemma3:12b/assembly/2606 create mode 100644 results/classifier/gemma3:12b/assembly/2613 create mode 100644 results/classifier/gemma3:12b/assembly/2627 create mode 100644 results/classifier/gemma3:12b/assembly/2696 create mode 100644 results/classifier/gemma3:12b/assembly/2711 create mode 100644 results/classifier/gemma3:12b/assembly/2730 create mode 100644 results/classifier/gemma3:12b/assembly/2802 create mode 100644 results/classifier/gemma3:12b/assembly/2870 create mode 100644 results/classifier/gemma3:12b/assembly/2871 create mode 100644 results/classifier/gemma3:12b/assembly/2970 create mode 100644 results/classifier/gemma3:12b/assembly/2972 create mode 100644 results/classifier/gemma3:12b/assembly/364 create mode 100644 results/classifier/gemma3:12b/assembly/372 create mode 100644 results/classifier/gemma3:12b/assembly/422 create mode 100644 results/classifier/gemma3:12b/assembly/47 create mode 100644 results/classifier/gemma3:12b/assembly/480 create mode 100644 results/classifier/gemma3:12b/assembly/491 create mode 100644 results/classifier/gemma3:12b/assembly/494 create mode 100644 results/classifier/gemma3:12b/assembly/509 create mode 100644 results/classifier/gemma3:12b/assembly/571 create mode 100644 results/classifier/gemma3:12b/assembly/613 create mode 100644 results/classifier/gemma3:12b/assembly/63 create mode 100644 results/classifier/gemma3:12b/assembly/683 create mode 100644 results/classifier/gemma3:12b/assembly/695 create mode 100644 results/classifier/gemma3:12b/assembly/710 create mode 100644 results/classifier/gemma3:12b/assembly/713 create mode 100644 results/classifier/gemma3:12b/assembly/788886 create mode 100644 results/classifier/gemma3:12b/assembly/799 create mode 100644 results/classifier/gemma3:12b/assembly/863 create mode 100644 results/classifier/gemma3:12b/assembly/881637 create mode 100644 results/classifier/gemma3:12b/assembly/889053 create mode 100644 results/classifier/gemma3:12b/assembly/890 create mode 100644 results/classifier/gemma3:12b/assembly/947 create mode 100644 results/classifier/gemma3:12b/assembly/953 create mode 100644 results/classifier/gemma3:12b/assembly/979 create mode 100644 results/classifier/gemma3:12b/assembly/984 create mode 100644 results/classifier/gemma3:12b/assembly/996798 (limited to 'results/classifier/gemma3:12b/assembly') 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: + + + ../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, + +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 +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 + Signed-off-by: Paolo Bonzini + + 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 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 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 ` == `. 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`, ` == `. + +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 +#include + +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 + +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 +#include + +#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 +#include + +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 +#include +#include + +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):
+`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` + +Run with:
+`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