diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-06 16:43:19 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-06 16:43:19 +0000 |
| commit | 238ec2b7cc1557d6f34c33cc482e4d0cd3e266dd (patch) | |
| tree | cd8a1b75ba7b3543eb7fe6857f408e7be4d9fd0b /results/classifier/gemma3:27b/instruction/1820686 | |
| parent | 96049c939b1916d80532630d63c14e04d5244f1d (diff) | |
| download | qemu-analysis-238ec2b7cc1557d6f34c33cc482e4d0cd3e266dd.tar.gz qemu-analysis-238ec2b7cc1557d6f34c33cc482e4d0cd3e266dd.zip | |
add results
Diffstat (limited to 'results/classifier/gemma3:27b/instruction/1820686')
| -rw-r--r-- | results/classifier/gemma3:27b/instruction/1820686 | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/results/classifier/gemma3:27b/instruction/1820686 b/results/classifier/gemma3:27b/instruction/1820686 new file mode 100644 index 000000000..a141dce7d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1820686 @@ -0,0 +1,8 @@ + + + +risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' + +QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. + +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. \ No newline at end of file |