diff options
Diffstat (limited to 'results/classifier/phi4:14b/output/instruction')
58 files changed, 1622 insertions, 0 deletions
diff --git a/results/classifier/phi4:14b/output/instruction/1044 b/results/classifier/phi4:14b/output/instruction/1044 new file mode 100644 index 000000000..683946032 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1044 @@ -0,0 +1,4 @@ + + + +Warning: libevent-loop-base.a the table of contents is empty diff --git a/results/classifier/phi4:14b/output/instruction/1079080 b/results/classifier/phi4:14b/output/instruction/1079080 new file mode 100644 index 000000000..069bd5e2b --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1079080 @@ -0,0 +1,13 @@ + + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1156 b/results/classifier/phi4:14b/output/instruction/1156 new file mode 100644 index 000000000..76296a60b --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1156 @@ -0,0 +1,4 @@ + + + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/phi4:14b/output/instruction/1178 b/results/classifier/phi4:14b/output/instruction/1178 new file mode 100644 index 000000000..ffe5b226f --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1178 @@ -0,0 +1,4 @@ + + + +is that riscv64 `feq.s` only should consider the lowest 32-bits. diff --git a/results/classifier/phi4:14b/output/instruction/1245543 b/results/classifier/phi4:14b/output/instruction/1245543 new file mode 100644 index 000000000..6ca865d95 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1245543 @@ -0,0 +1,26 @@ + + + +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/phi4:14b/output/instruction/1248 b/results/classifier/phi4:14b/output/instruction/1248 new file mode 100644 index 000000000..49134e68b --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1248 @@ -0,0 +1,14 @@ + + + +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/phi4:14b/output/instruction/1339 b/results/classifier/phi4:14b/output/instruction/1339 new file mode 100644 index 000000000..dd0af5e85 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1339 @@ -0,0 +1,19 @@ + + + +RVV vfncvt.rtz.x.f.w Assertion failed +Description of problem: +when execute +``` +vsetvli t0, x0, e16, m1 +vfncvt.rtz.x.f.w v0, v4 +``` +report error: + +qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped) +Steps to reproduce: +1. write the code +2. compile +3. excute +Additional information: + diff --git a/results/classifier/phi4:14b/output/instruction/1370 b/results/classifier/phi4:14b/output/instruction/1370 new file mode 100644 index 000000000..da284a401 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1370 @@ -0,0 +1,16 @@ + + + +x86 BLSI and BLSR semantic bug +Description of problem: +The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("blsi rax, rbx"); +} +``` +2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/phi4:14b/output/instruction/1371 b/results/classifier/phi4:14b/output/instruction/1371 new file mode 100644 index 000000000..a77c0b1fe --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1371 @@ -0,0 +1,22 @@ + + + +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/phi4:14b/output/instruction/1374 b/results/classifier/phi4:14b/output/instruction/1374 new file mode 100644 index 000000000..f23fdda34 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1374 @@ -0,0 +1,25 @@ + + + +x86 BZHI semantic bug +Description of problem: +The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xb1aa9da2fe33fe3"); + asm("mov rbx, 0x80000000ffffffff"); + asm("mov rcx, 0xf3fce8829b99a5c6"); + asm("bzhi rax, rbx, rcx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x0x80000000ffffffff + - SF = 1 + - QEMU + - RAX = 0xffffffff + - SF = 0 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/phi4:14b/output/instruction/1377 b/results/classifier/phi4:14b/output/instruction/1377 new file mode 100644 index 000000000..b8faf56e9 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1377 @@ -0,0 +1,16 @@ + + +x86 CVT* series instructions fault +Description of problem: +For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + mmap(0x555555559000, 0x1000, flag, ~~, 0); + asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); +} +``` +2. Execute. QEMU crashes but CPU does not. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/phi4:14b/output/instruction/1452 b/results/classifier/phi4:14b/output/instruction/1452 new file mode 100644 index 000000000..d0390a57f --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1452 @@ -0,0 +1,4 @@ + + + +Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/phi4:14b/output/instruction/1469342 b/results/classifier/phi4:14b/output/instruction/1469342 new file mode 100644 index 000000000..31e8630a1 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1469342 @@ -0,0 +1,6 @@ + + + +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/phi4:14b/output/instruction/1512 b/results/classifier/phi4:14b/output/instruction/1512 new file mode 100644 index 000000000..ff48c0904 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1512 @@ -0,0 +1,4 @@ + + + +AVX/AVX2 not correcly detected in user mode diff --git a/results/classifier/phi4:14b/output/instruction/1737 b/results/classifier/phi4:14b/output/instruction/1737 new file mode 100644 index 000000000..9ee7e33cc --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1737 @@ -0,0 +1,52 @@ + + + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/phi4:14b/output/instruction/1741 b/results/classifier/phi4:14b/output/instruction/1741 new file mode 100644 index 000000000..64d3f1c15 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1741 @@ -0,0 +1,4 @@ + + + +95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/phi4:14b/output/instruction/1751422 b/results/classifier/phi4:14b/output/instruction/1751422 new file mode 100644 index 000000000..81442661b --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1751422 @@ -0,0 +1,7 @@ + + + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1771 b/results/classifier/phi4:14b/output/instruction/1771 new file mode 100644 index 000000000..818e547e8 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1771 @@ -0,0 +1,36 @@ + + + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/phi4:14b/output/instruction/1780 b/results/classifier/phi4:14b/output/instruction/1780 new file mode 100644 index 000000000..dd71873ae --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1780 @@ -0,0 +1,20 @@ + + + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/phi4:14b/output/instruction/1815024 b/results/classifier/phi4:14b/output/instruction/1815024 new file mode 100644 index 000000000..7376befa4 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1815024 @@ -0,0 +1,18 @@ + + + +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/phi4:14b/output/instruction/1826568 b/results/classifier/phi4:14b/output/instruction/1826568 new file mode 100644 index 000000000..cebbffe97 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1826568 @@ -0,0 +1,16 @@ + + + +RISC-V Disassembler/translator instruction decoding disagreement + + +When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: + + 0x000000008002cade: 051300009517e2bf illegal + Disassembler disagrees with translator over instruction decoding + Please report this to <email address hidden> + + +You may want to resolve the disagreement. + +Axel \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1828867 b/results/classifier/phi4:14b/output/instruction/1828867 new file mode 100644 index 000000000..a17fd5b58 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1828867 @@ -0,0 +1,11 @@ + + + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1881450 b/results/classifier/phi4:14b/output/instruction/1881450 new file mode 100644 index 000000000..37d7e0e6e --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1881450 @@ -0,0 +1,26 @@ + + + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125 \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1889288 b/results/classifier/phi4:14b/output/instruction/1889288 new file mode 100644 index 000000000..352290089 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1889288 @@ -0,0 +1,10 @@ + + + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1898954 b/results/classifier/phi4:14b/output/instruction/1898954 new file mode 100644 index 000000000..19fd0521e --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1898954 @@ -0,0 +1,29 @@ + + +x86 f1 opcode hangs qemu + +I have qemu installed and running in linux and windows +in linux i execute the following simple code in real mode of cpu in my vm +90 nop +90 nop +90 nop +f1 ;this should conjure up my interrupt handler from ivt int 1 +--------- end of code ---- +it works properly in vbox,qemu linux,and even in my boot loder +on a real platform + it doeas not work fine in windows 10 (32 bit efi) based qemu +--- +all of the below was retyped there may be typo +so onwards to the flawed software +********** for qemu-system-x86_64.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +********** for qemu-system-i386.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +*********************************************** +my startup code is +"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc +--- +also same flaw if i change above section to +"d:\programs\qemu\qemu-system-i386.exe" \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1925512 b/results/classifier/phi4:14b/output/instruction/1925512 new file mode 100644 index 000000000..a847cd79a --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1925512 @@ -0,0 +1,21 @@ + + + +UNDEFINED case for instruction BLX + +Hi + +I refer to the instruction BLX imm (T2 encoding) in ARMv7 (Thumb mode). + +11110 S imm10H 11 J1 0 J2 imm10L H + + +if H == '1' then UNDEFINED; +I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:'00', 32); +targetInstrSet = InstrSet_A32; +if InITBlock() && !LastInITBlock() then UNPREDICTABLE; + +According to the manual, if H equals to 1, this instruction should be an UNDEFINED instruction. However, it seems QEMU does not check this constraint in function trans_BLX_i. Thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/1941 b/results/classifier/phi4:14b/output/instruction/1941 new file mode 100644 index 000000000..4624fd6d6 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/1941 @@ -0,0 +1,105 @@ + + + +ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values +Description of problem: +The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. + +Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): +``` +xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {0, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} +xvcvspuxds ({1, 2, nan, nan}) = {0, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} + +xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {0, 0} +``` + +Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): +``` +xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {2, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} +xvcvspuxds ({1, 2, nan, nan}) = {2, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} +xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} +xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} + +xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {1, 0} +``` +Steps to reproduce: +1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` +2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le +3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. +Additional information: +Attachments: +- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) +- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 +- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/phi4:14b/output/instruction/2083 b/results/classifier/phi4:14b/output/instruction/2083 new file mode 100644 index 000000000..ca2fcabbd --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2083 @@ -0,0 +1,114 @@ + + + +AArch64 SME SMOPA (4-way) outer product instruction gives incorrect result +Description of problem: +The SME SMOPA (4-way) instruction ([spec](https://developer.arm.com/documentation/ddi0602/2023-09/SME-Instructions/SMOPA--4-way---Signed-integer-sum-of-outer-products-and-accumulate-?lang=en)) is giving incorrect result. Example below for 8-bit variant, which is equivalent to following Python example (128-bit VL) to make it clearer: + +``` +import numpy as np +vl = 128 +esize = 32 +dim = vl // esize + +A = range(16) +B = range(16, 32) +C = np.zeros((4, 4,), dtype=np.int32) + +for row in range(dim): + for col in range(dim): + for k in range(4): + C[row, col] += A[4*row + k] * B[4*col + k] + +print(C) + +[[ 110 134 158 182] + [ 390 478 566 654] + [ 670 822 974 1126] + [ 950 1166 1382 1598]] +``` + +main.c +``` +#include <stdio.h> +#include <stdint.h> + +void foo(int *dst); + +int main() { + int32_t dst[16]; + foo(dst); + + // This should print: + // >>> 110 134 158 182 + // >>> 390 478 566 654 + // >>> 670 822 974 1126 + // >>> 950 1166 1382 1598 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%d ", dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S + +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.b + index z0.b, #0, #1 + mov z1.d, z0.d + add z1.b, z1.b, #16 + + zero {za} + smopa za0.s, p0/m, p0/m, z0.b, z1.b + + // Read the first 4x4 sub-matrix of elements from tile 0: + mov w12, #0 + mova z0.s, p0/m, za0h.s[w12, #0] + mova z1.s, p0/m, za0h.s[w12, #1] + mova z2.s, p0/m, za0h.s[w12, #2] + mova z3.s, p0/m, za0h.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme main.c foo.S +$ ~/qemu/build/qemu-aarch64 -cpu max,sme128=on a.out +>>> 110 478 158 654 +>>> 0 0 0 0 +>>> 670 1166 974 1598 +>>> 0 0 0 0 +``` +Additional information: + diff --git a/results/classifier/phi4:14b/output/instruction/2089 b/results/classifier/phi4:14b/output/instruction/2089 new file mode 100644 index 000000000..42ff91e11 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2089 @@ -0,0 +1,30 @@ + + + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/phi4:14b/output/instruction/2119 b/results/classifier/phi4:14b/output/instruction/2119 new file mode 100644 index 000000000..c2d7b188c --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2119 @@ -0,0 +1,4 @@ + + + +target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed when the single-letter V is enabled diff --git a/results/classifier/phi4:14b/output/instruction/2203 b/results/classifier/phi4:14b/output/instruction/2203 new file mode 100644 index 000000000..b2e549ee0 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2203 @@ -0,0 +1,4 @@ + + + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/phi4:14b/output/instruction/2372 b/results/classifier/phi4:14b/output/instruction/2372 new file mode 100644 index 000000000..007c25eab --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2372 @@ -0,0 +1,112 @@ + + + +A bug in AArch64 UMOPA/UMOPS (4-way) instruction +Description of problem: +umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element. + +However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation: +``` +// target/arm/tcg/sme_helper.c +#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \ +static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \ +{ \ + uint64_t sum = 0; \ + /* Apply P to N as a mask, making the inactive elements 0. */ \ + n &= expand_pred_h(p); \ + sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); \ + sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16); \ + sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32); \ + sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48); \ + return neg ? a - sum : a + sum; \ +} + +DEF_IMOP_64(umopa_d, uint16_t, uint16_t) +``` +When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P1[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z20[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA2H[128] = { 0x0, }; +char o_ZA2H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA2H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P1\n" + "add x29, x29, :lo12:i_P1\n" + "ldr p1, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z20\n" + "add x29, x29, :lo12:i_Z20\n" + "ldr z20, [x29]\n" + "adrp x29, i_ZA2H\n" + "add x29, x29, :lo12:i_ZA2H\n" + "mov x15, 0\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + ".inst 0xa1f43402\n" // umopa za2.d, p5/m, p1/m, z0.h, z20.h + "adrp x29, o_ZA2H\n" + "add x29, x29, :lo12:o_ZA2H\n" + "mov x15, 0\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "smstop\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/phi4:14b/output/instruction/2486 b/results/classifier/phi4:14b/output/instruction/2486 new file mode 100644 index 000000000..6cd7e0640 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2486 @@ -0,0 +1,15 @@ + + + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/phi4:14b/output/instruction/2497 b/results/classifier/phi4:14b/output/instruction/2497 new file mode 100644 index 000000000..92bc09806 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2497 @@ -0,0 +1,6 @@ + + + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/phi4:14b/output/instruction/2498 b/results/classifier/phi4:14b/output/instruction/2498 new file mode 100644 index 000000000..bf51612fa --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2498 @@ -0,0 +1,54 @@ + + + +m68k: fpu: fmovem with multiple control registers has incorrect in memory order +Description of problem: +It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers. + +According to the manual: + +``` +The +registers are always moved in the same order, regardless of the addressing mode +used; the floating-point control register is moved first, followed by the floating-point +status register, and the floating-point instruction address register is moved last. +``` + +Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary. + +Maybe something like this is needed: + +``` diff +commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt) +Author: Daniel Palmer <daniel@thingy.jp> +Date: Tue Aug 13 09:52:54 2024 +0900 + + fix fmovem ordering + +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index 92dc9d8563..64ff2df06e 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + */ + + if (is_write && mode == 4) { +- for (i = 2; i >= 0; i--, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + gen_qemu_store_fcr(s, addr, 1 << i); + if (mask != 1) { + tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG)); +@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + } + tcg_gen_mov_i32(AREG(insn, 0), addr); + } else { +- for (i = 0; i < 3; i++, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + if (is_write) { + gen_qemu_store_fcr(s, addr, 1 << i); + } else { +``` diff --git a/results/classifier/phi4:14b/output/instruction/2499 b/results/classifier/phi4:14b/output/instruction/2499 new file mode 100644 index 000000000..f6bfb80d5 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2499 @@ -0,0 +1,33 @@ + + + +m68k: fpu: fsave/frestore should be enabled for 68020/68030 +Description of problem: +valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception. + +I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences. + +``` diff +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index d5d2322329..92dc9d8563 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore) + gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE); + return; + } +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + SRC_EA(env, addr, OS_LONG, 0, NULL); + /* FIXME: check the state frame */ + } else { +@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave) + return; + } + +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + /* always write IDLE */ + TCGv idle = tcg_constant_i32(0x41000000); + DEST_EA(env, insn, OS_LONG, idle, NULL); +``` diff --git a/results/classifier/phi4:14b/output/instruction/2500 b/results/classifier/phi4:14b/output/instruction/2500 new file mode 100644 index 000000000..a23fcaed6 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2500 @@ -0,0 +1,7 @@ + + + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/phi4:14b/output/instruction/2536 b/results/classifier/phi4:14b/output/instruction/2536 new file mode 100644 index 000000000..afd1e571a --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2536 @@ -0,0 +1,4 @@ + + + +Dynamic translation issue of arm instruction VFNMA and VFNMS diff --git a/results/classifier/phi4:14b/output/instruction/2595 b/results/classifier/phi4:14b/output/instruction/2595 new file mode 100644 index 000000000..07e871de6 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2595 @@ -0,0 +1,138 @@ + + + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include <stdio.h> + #include <arm_sve.h> + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/phi4:14b/output/instruction/2606 b/results/classifier/phi4:14b/output/instruction/2606 new file mode 100644 index 000000000..060630676 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2606 @@ -0,0 +1,201 @@ + + + +PowerPC host code is broken on Darwin +Description of problem: +Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI. +Steps to reproduce: +1. Run the build of qemu on Darwin ppc, see it fail. +Additional information: +This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes): +``` +--- common-user/host/ppc/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc/safe-syscall.inc.S 2023-08-18 18:08:15.000000000 +0800 +@@ -25,17 +25,11 @@ + # else + # error "Unknown ABI" + # endif +-#endif +- +-#ifndef _CALL_SYSV +-# error "Unsupported ABI" + #endif + +- + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -47,11 +41,8 @@ + * arguments being syscall arguments (also 'long'). + */ + safe_syscall_base: +- .cfi_startproc +- stwu 1, -8(1) +- .cfi_def_cfa_offset 8 +- stw 30, 4(1) +- .cfi_offset 30, -4 ++ stwu r1, -8(r1) ++ stw r30, 4(r1) + + /* + * We enter with r3 == &signal_pending +@@ -64,14 +55,14 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- mr 30, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ mr r30, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* + * This next sequence of code works in conjunction with the +@@ -83,25 +74,22 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(30) +- cmpwi 0, 12, 0 ++ lwz r12, 0(r30) ++ cmpwi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- lwz 30, 4(1) /* restore r30 */ +- addi 1, 1, 8 /* restore stack */ +- .cfi_restore 30 +- .cfi_def_cfa_offset 0 ++ lwz r30, 4(r1) /* restore r30 */ ++ addi r1, r1, 8 /* restore stack */ ++ + bnslr+ /* return on success */ + b safe_syscall_set_errno_tail + + /* code path when we didn't execute the syscall */ +-2: lwz 30, 4(1) +- addi 1, 1, 8 +- addi 3, 0, QEMU_ERESTARTSYS ++2: lwz r30, 4(r1) ++ addi r1, r1, 8 ++ addi r3, 0, QEMU_ERESTARTSYS + b safe_syscall_set_errno_tail + +- .cfi_endproc +- + .size safe_syscall_base, .-safe_syscall_base + + +--- common-user/host/ppc64/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc64/safe-syscall.inc.S 2022-05-31 13:23:21.000000000 +0800 +@@ -13,7 +13,6 @@ + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -23,19 +22,10 @@ + * second one the system call number (as a 'long'), and all further + * arguments being syscall arguments (also 'long'). + */ +-#if _CALL_ELF == 2 +-safe_syscall_base: +- .cfi_startproc +- .localentry safe_syscall_base,0 +-#else +- .section ".opd","aw" ++ + .align 3 + safe_syscall_base: +- .quad .L.safe_syscall_base,.TOC.@tocbase,0 +- .previous +-.L.safe_syscall_base: +- .cfi_startproc +-#endif ++ + /* We enter with r3 == &signal_pending + * r4 == syscall number + * r5 ... r10 == syscall arguments +@@ -46,16 +36,15 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- std 14, 16(1) /* Preserve r14 in SP+16 */ +- .cfi_offset 14, 16 +- mr 14, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ std r14, 16(r1) /* Preserve r14 in SP+16 */ ++ mr r14, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* This next sequence of code works in conjunction with the + * rewind_if_safe_syscall_function(). If a signal is taken +@@ -66,29 +55,20 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(14) +- cmpwi 0, 12, 0 ++ ld r12, 0(r14) ++ cmpdi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- ld 14, 16(1) /* restore r14 */ ++ ld r14, 16(r1) /* restore r14 */ + bso- 1f + blr + + /* code path when we didn't execute the syscall */ +-2: ld 14, 16(1) /* restore r14 */ +- addi 3, 0, QEMU_ERESTARTSYS ++2: ld r14, 16(r1) /* restore r14 */ ++ addi r3, 0, QEMU_ERESTARTSYS + + /* code path setting errno */ + 1: b safe_syscall_set_errno_tail + nop /* per abi, for the linker to modify */ +- +- .cfi_endproc +- +-#if _CALL_ELF == 2 +- .size safe_syscall_base, .-safe_syscall_base +-#else +- .size safe_syscall_base, .-.L.safe_syscall_base +- .size .L.safe_syscall_base, .-.L.safe_syscall_base +-#endif +``` +(Obviously, it is not made in a portable way – that was not needed at the time.) + +Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance. diff --git a/results/classifier/phi4:14b/output/instruction/2696 b/results/classifier/phi4:14b/output/instruction/2696 new file mode 100644 index 000000000..3fdc8f0a0 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2696 @@ -0,0 +1,15 @@ + + + +qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction +Description of problem: +``` +❯ cat start.s +.globl _start +_start: .word 0 +❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld +❯ qemu-hexagon ./a.out +** +ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +``` diff --git a/results/classifier/phi4:14b/output/instruction/2878 b/results/classifier/phi4:14b/output/instruction/2878 new file mode 100644 index 000000000..0cf0f9d8c --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2878 @@ -0,0 +1,4 @@ + + + +Support for avx512 in qemu user space emulation. diff --git a/results/classifier/phi4:14b/output/instruction/2971 b/results/classifier/phi4:14b/output/instruction/2971 new file mode 100644 index 000000000..706ee9d06 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/2971 @@ -0,0 +1,47 @@ + + + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/phi4:14b/output/instruction/312 b/results/classifier/phi4:14b/output/instruction/312 new file mode 100644 index 000000000..eeba93125 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/312 @@ -0,0 +1,4 @@ + + + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/phi4:14b/output/instruction/333 b/results/classifier/phi4:14b/output/instruction/333 new file mode 100644 index 000000000..674954ef0 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/333 @@ -0,0 +1,4 @@ + + + +random errors on aarch64 when executing __aarch64_cas8_acq_rel diff --git a/results/classifier/phi4:14b/output/instruction/361 b/results/classifier/phi4:14b/output/instruction/361 new file mode 100644 index 000000000..afcbbb584 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/361 @@ -0,0 +1,4 @@ + + + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/phi4:14b/output/instruction/385 b/results/classifier/phi4:14b/output/instruction/385 new file mode 100644 index 000000000..1b07af179 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/385 @@ -0,0 +1,4 @@ + + + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/phi4:14b/output/instruction/422 b/results/classifier/phi4:14b/output/instruction/422 new file mode 100644 index 000000000..d637043bf --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/422 @@ -0,0 +1,4 @@ + + + +Unable to execute MIPS MSA code due to illegal instruction diff --git a/results/classifier/phi4:14b/output/instruction/427 b/results/classifier/phi4:14b/output/instruction/427 new file mode 100644 index 000000000..87592bc9b --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/427 @@ -0,0 +1,4 @@ + + + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/phi4:14b/output/instruction/449 b/results/classifier/phi4:14b/output/instruction/449 new file mode 100644 index 000000000..7b194c316 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/449 @@ -0,0 +1,71 @@ + + + +s390x linux-user assertion fires in vector asm on master +Description of problem: +Seeing a assert being fired when running this go program that executes vector instructions: + +[ecdsaexample.go](/uploads/f5162a12747f93f060cfcabaea786d92/ecdsaexample.go) + +``` +qemu-s390x-static: ../qemu/target/s390x/translate.c:1063: get_field1: Assertion `have_field1(s, o)' failed. +SIGABRT: abort +PC=0x5b660 m=0 sigcode=4294967290 + +goroutine 1 [running]: +runtime.sigpanic() + /home/jalbrecht/s390x/15/go/src/runtime/signal_unix.go:723 fp=0xc000198998 sp=0xc000198998 pc=0x5b660 +crypto/elliptic.p256SqrInternalVMSL() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1488 fp=0xc0001989a0 sp=0xc0001989a0 pc=0xda600 +p256SqrInternal() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1695 +0x18 fp=0xc0001989d8 sp=0xc0001989a0 pc=0xd95b8 +crypto/elliptic.p256SqrAsm(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20, 0x0, 0xc, 0x30, 0x4000802560, ...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1849 +0x3c fp=0xc0001989e0 sp=0xc0001989d8 pc=0xdaa6c +crypto/elliptic.p256Sqr(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:81 +crypto/elliptic.p256Inverse(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:324 +0x66 fp=0xc000198b28 sp=0xc0001989e0 pc=0xd7da6 +crypto/elliptic.initTable() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:436 +0x192 fp=0xc000198d00 sp=0xc000198b28 pc=0xd87d2 +crypto/elliptic.initP256Arch(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:57 +crypto/elliptic.initP256() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256.go:40 +0x2c0 fp=0xc000198d38 sp=0xc000198d00 pc=0xd2960 +crypto/elliptic.initAll() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:397 +0x24 fp=0xc000198d40 sp=0xc000198d38 pc=0xd1ab4 +sync.(*Once).doSlow(0x2168e8, 0x122be8) + /home/jalbrecht/s390x/15/go/src/sync/once.go:66 +0x12c fp=0xc000198d98 sp=0xc000198d40 pc=0x7ee5c +sync.(*Once).Do(...) + /home/jalbrecht/s390x/15/go/src/sync/once.go:57 +crypto/elliptic.P256(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:433 +main.main() + /home/jalbrecht/s390x/ecdsaexample.go:17 +0x7de fp=0xc000198f80 sp=0xc000198d98 pc=0xe4a2e +runtime.main() + /home/jalbrecht/s390x/15/go/src/runtime/proc.go:204 +0x214 fp=0xc000198fd8 sp=0xc000198f80 pc=0x472e4 +runtime.goexit() + /home/jalbrecht/s390x/15/go/src/runtime/asm_s390x.s:779 +0x2 fp=0xc000198fd8 sp=0xc000198fd8 pc=0x77c52 + +r0 0x0 r1 0xc000198bc0 +r2 0xc000198ce0 r3 0xc000198ce0 +r4 0x1401a0 r5 0xc000198be0 +r6 0xc000198bc0 r7 0x1c00f0 +r8 0xda600 r9 0xc0001989a8 +r10 0x217810 r11 0x0 +r12 0x4000800378 r13 0xc000000180 +r14 0xda600 r15 0xc000198998 +pc 0x5b660 link 0xda600 +exit status 2 +``` +Steps to reproduce: +On an amd64 linux host: +1. Download attached ecdsaexample.go file +2. Download and untar an s390x go distro (1.15 and 1.16 both show this issue): https://golang.org/dl/go1.15.13.linux-s390x.tar.gz +3. Build a qemu-s390x-static from current master +4. qemu-s390x-static -E PATH=/path/to/s390x/15/go/bin -L /usr/s390x-linux-gnu /path/to/s390x/15/go/bin/go run ecdsaexample.go +Additional information: +@davidhildenbrand could you have a look? I tracked it down to this series of patches: https://lore.kernel.org/qemu-devel/20210608092337.12221-1-david@redhat.com/. I tried reverting just this series from current master and then the program runs with no issues. + +This crash is seen whenever eg. certificates are checked when connecting via https so it is likely to happen in real programs. + +cc: @ruixinbao diff --git a/results/classifier/phi4:14b/output/instruction/570 b/results/classifier/phi4:14b/output/instruction/570 new file mode 100644 index 000000000..325d5ea7a --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/570 @@ -0,0 +1,4 @@ + + + +linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined diff --git a/results/classifier/phi4:14b/output/instruction/695 b/results/classifier/phi4:14b/output/instruction/695 new file mode 100644 index 000000000..9b14ae6c3 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/695 @@ -0,0 +1,4 @@ + + + +MIPS: nanomips p32 ABI not supported diff --git a/results/classifier/phi4:14b/output/instruction/799 b/results/classifier/phi4:14b/output/instruction/799 new file mode 100644 index 000000000..2a038a0be --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/799 @@ -0,0 +1,50 @@ + + + +TCG Optimizer crashes on AArch64 SVE2 instruction +Description of problem: +QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: +``` +Unrecognized operation 145 in do_constant_folding. +../tcg/optimize.c:458: tcg fatal error +``` +Steps to reproduce: +1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) +```asm +.org 0x0 +entry: + mrs x1, cptr_el3 + orr x9, x1, #0x100 + msr cptr_el3, x9 + + msr cptr_el2, xzr + + mov x1, #0x3 + mrs x9, cpacr_el1 + bfi x9, x1, #16, #2 + bfi x9, x1, #20, #2 + msr cpacr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el2, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el3, x9 + + uqxtnt z11.s, z22.d +``` +2. Execute it using the command line given above. +Additional information: +I tested latest master as well, and the problem persists. diff --git a/results/classifier/phi4:14b/output/instruction/824 b/results/classifier/phi4:14b/output/instruction/824 new file mode 100644 index 000000000..a93e2e869 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/824 @@ -0,0 +1,15 @@ + + + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/phi4:14b/output/instruction/826 b/results/classifier/phi4:14b/output/instruction/826 new file mode 100644 index 000000000..d79f7cf28 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/826 @@ -0,0 +1,19 @@ + + + +AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated +Description of problem: +During execution of the following SVE2 instruction: +`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` +with the following register state: +``` +(gdb) p $p3 +$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} +(gdb) p $z14.d.u +$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} +(gdb) p $x9 +$3 = 0x0 +``` +QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. +Additional information: +A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/phi4:14b/output/instruction/890 b/results/classifier/phi4:14b/output/instruction/890 new file mode 100644 index 000000000..26d32f2ea --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/890 @@ -0,0 +1,4 @@ + + + +Misinterpretation of arm neon invalid insn diff --git a/results/classifier/phi4:14b/output/instruction/904308 b/results/classifier/phi4:14b/output/instruction/904308 new file mode 100644 index 000000000..93fdd56b6 --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/904308 @@ -0,0 +1,101 @@ + + + +x86: BT/BTS/BTR/BTC: ZF flag is unaffected + +Hello! + +Bug was found in qemu.git. +See target-i386/translate.c: + + case 0x1ba: /* bt/bts/btr/btc Gv, im */ + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + op = (modrm >> 3) & 7; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + if (mod != 3) { + s->rip_offset = 1; + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + /* load shift */ + val = ldub_code(s->pc++); + gen_op_movl_T1_im(val); + if (op < 4) + goto illegal_op; + op -= 4; + goto bt_op; + case 0x1a3: /* bt Gv, Ev */ + op = 0; + goto do_btx; + case 0x1ab: /* bts */ + op = 1; + goto do_btx; + case 0x1b3: /* btr */ + op = 2; + goto do_btx; + case 0x1bb: /* btc */ + op = 3; + do_btx: + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + reg = ((modrm >> 3) & 7) | rex_r; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + gen_op_mov_TN_reg(OT_LONG, 1, reg); + if (mod != 3) { + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + /* specific case: we need to add a displacement */ + gen_exts(ot, cpu_T[1]); + tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot); + tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot); + tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + bt_op: + tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1); + switch(op) { + case 0: + tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + break; + case 1: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + case 2: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_not_tl(cpu_tmp0, cpu_tmp0); + tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + default: + case 3: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + } + s->cc_op = CC_OP_SARB + ot; + if (op != 0) { + if (mod != 3) + gen_op_st_T0_A0(ot + s->mem_index); + else + gen_op_mov_reg_T0(ot, rm); + tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + } + break; + +always set zf... + +There is fixed patch. \ No newline at end of file diff --git a/results/classifier/phi4:14b/output/instruction/979 b/results/classifier/phi4:14b/output/instruction/979 new file mode 100644 index 000000000..3c6e7967d --- /dev/null +++ b/results/classifier/phi4:14b/output/instruction/979 @@ -0,0 +1,10 @@ + + + +s390x floating point conversion functions broken +Description of problem: +While collecting additional reference files for float_convs (and float_convd) I noticed that the s390x handling of some cases is broken. See diff for details: + +``` + diff -y tests/tcg/s390x-linux-user/float_convs.out ../../tests/tcg/s390x/float_convs.ref +# |