diff options
Diffstat (limited to 'results/classifier/semantic-bugs/assembly')
| -rw-r--r-- | results/classifier/semantic-bugs/assembly/1612 | 64 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/assembly/1620 | 107 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/assembly/1649 | 30 | ||||
| -rw-r--r-- | results/classifier/semantic-bugs/assembly/904 | 29 |
4 files changed, 230 insertions, 0 deletions
diff --git a/results/classifier/semantic-bugs/assembly/1612 b/results/classifier/semantic-bugs/assembly/1612 new file mode 100644 index 00000000..aa2f4e52 --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/1612 @@ -0,0 +1,64 @@ +assembly: 0.776 +instruction: 0.670 +graphic: 0.648 +semantic: 0.641 +device: 0.599 +other: 0.486 +network: 0.456 +socket: 0.453 +boot: 0.407 +vnc: 0.367 +mistranslation: 0.229 +KVM: 0.225 + +SVE first-faulting gather loads return incorrect data +Description of problem: +The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. +Steps to reproduce: +1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`. + +asmtest.s +``` + .type asmtest, @function + .balign 16 + .global asmtest +asmtest: + setffr + ptrue p0.d + index z1.d, #0, #1 + ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] + rdffr p1.b + st1d {z1.d}, p0, [x1] + str p1, [x2] + ret +``` + +This harness for convenience intialises some data and checks the element at index 1, which should be 1. + +test.c +``` +#include <arm_sve.h> +#include <stdio.h> + +void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); + +int main() { + const int64_t data[] = {42, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, + 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, + 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}; + svint64_t loaded; + svbool_t ffr; + + asmtest(data, &loaded, &ffr); + + // Check value of element at index 1 + svuint64_t lanes = svindex_u64(0, 1); + svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); + printf("%ld\n", svaddv_s64(lane, loaded)); +} +``` + +2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` +3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. +Additional information: +The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/semantic-bugs/assembly/1620 b/results/classifier/semantic-bugs/assembly/1620 new file mode 100644 index 00000000..ecfad33c --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/1620 @@ -0,0 +1,107 @@ +assembly: 0.775 +other: 0.747 +device: 0.720 +KVM: 0.715 +instruction: 0.707 +mistranslation: 0.702 +semantic: 0.688 +graphic: 0.672 +vnc: 0.639 +socket: 0.616 +boot: 0.561 +network: 0.554 + +SME FMOPA outer product instruction gives incorrect result +Description of problem: +The SME outer product instructions operate on tiles of elements. In the +below example we are performing an outer product of a vector of 1.0 +by itself. This naturally should produce a matrix filled with 1.0 +values, however if we read the values of the tile and printf them we +instead observe 0.0 values. + +Without digging into the underlying QEMU code this appears to be a bug +in how elements are set based on the tile number, since the same code +using za0.s rather than za1.s correctly reports all 1.0 values as output +as expected. + +main.c +``` +#include <stdio.h> + +void foo(float *dst); + +int main() { + float dst[16]; + foo(dst); + + // This should print: + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%lf ", (double)dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.s, vl4 + fmov z0.s, #1.0 + + // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. + // Note that we are using tile 1 here (za1.s) rather than tile 0. + zero {za} + fmopa za1.s, p0/m, p0/m, z0.s, z0.s + + // Read the first 4x4 sub-matrix of elements from tile 1: + // Note that za1h should be interchangable here. + mov w12, #0 + mova z0.s, p0/m, za1v.s[w12, #0] + mova z1.s, p0/m, za1v.s[w12, #1] + mova z2.s, p0/m, za1v.s[w12, #2] + mova z3.s, p0/m, za1v.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static +$ ~/qemu/build/qemu-aarch64 ./a.out +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +``` diff --git a/results/classifier/semantic-bugs/assembly/1649 b/results/classifier/semantic-bugs/assembly/1649 new file mode 100644 index 00000000..7d78cca9 --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/1649 @@ -0,0 +1,30 @@ +assembly: 0.984 +instruction: 0.900 +graphic: 0.900 +device: 0.747 +semantic: 0.642 +vnc: 0.610 +network: 0.592 +socket: 0.542 +mistranslation: 0.500 +boot: 0.379 +KVM: 0.352 +other: 0.209 + +"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register +Description of problem: +slli a0, a0, 8 (1) + la a0, mtimvec (2) + csrw mtvec, a0 (3) + mtimvec: (4) + +For the above assembly snippet, the mtvec could be successfully set to the value of a0 +without the presence of the line (1) or with the shift amount being zero. However, +the mtvec can never be set successfully with the presence of line (1). +Steps to reproduce: +1. Create a test.s file and put these 4 lines of assembly into the file +2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S" +3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0. +4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value. +Additional information: + diff --git a/results/classifier/semantic-bugs/assembly/904 b/results/classifier/semantic-bugs/assembly/904 new file mode 100644 index 00000000..4946b814 --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/904 @@ -0,0 +1,29 @@ +assembly: 0.991 +instruction: 0.939 +graphic: 0.875 +device: 0.846 +semantic: 0.662 +network: 0.599 +mistranslation: 0.507 +vnc: 0.485 +boot: 0.425 +socket: 0.381 +KVM: 0.219 +other: 0.191 + +RISC-V: Cannot set SEIP bit of mip csr register in M mode +Description of problem: + +Steps to reproduce: +1. run assembly instructions **in M mode**: +``` +not t0, x0 // set t0 to 0b11..11 +csrs mip, t0 // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values) +csrr t1, mip // read value from mip to t1 +``` +2. GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set. +3. According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`. +4. According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`. +5. However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**. +Additional information: + |