Failure of UMUL16(X) instruction

[eflaner]

Instruction: 0XB1070677
Name of Instruction: UMUL16 (P-ext)
31..25 = 0b1011000
14..12 = 0b000
XLEN = RV64

operands:

op1: 0X7A3D52BEE581FA73
op2 :0X253EFDD7C7D6AE42

result:

expected: 0xb32720d6aa7abba6
received: 0xffffffffaa7abba6

elf attached as zip - generated using GNU Toolchain

runs on spike by running the command
spike --isa=rv64ip +signature=/dev/stdout tmpwfs3nkz1.elf signature-granularity=8

[aswaterman]

@hope51607

[hope51607]

Hi @eflaner, sorry, I can't reproduce your error in my environment.
Which g++ version did you use to compile spike?
I have tried g++9 and g++12, and both answers are correct.

[eflaner]

Which g++ version did you use to compile spike?

gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1)

[eflaner]

@hope51607 My bad, the zipped elf was wrong one - isn't coherent with the inputs.
can you try with tmpwg1k6zvu.zip - this contains the disassembly and the spike log

[hope51607]

@eflaner I tried the new elf but the answer is still correct.
By the way, so I use riscv-gcc pext pr to compile the following code to test

#include <rvp_intrinsic.h> 
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>

int main() {
  uint64_t result = __rv__umul16(0X7A3D52BEE581FA73, 0X253EFDD7C7D6AE42);
  printf("%016llx",result);

  return 0;
}

I think the cause of the umul16 wrong is the compiler version.
I will still try to reproduce the bug and fix it.
If you find anything please let me know.

[eflaner]

@hope51607 I'm actually using .word substitution instead of pext compiler
Here's the --commit-log

core   0: 3 0x0000000000001000 (0x00000297) x5  0x0000000000001000
core   0: 3 0x0000000000001004 (0x02028593) x11 0x0000000000001020
core   0: 3 0x0000000000001008 (0xf1402573) x10 0x0000000000000000
core   0: 3 0x000000000000100c (0x0182b283) x5  0x0000000080000000 mem 0x0000000000001018
core   0: 3 0x0000000000001010 (0x00028067)
core   0: 3 0x0000000080000000 (0x00000297) x5  0x0000000080000000
core   0: 3 0x0000000080000004 (0x06c28293) x5  0x000000008000006c
core   0: 3 0x0000000080000008 (0x30529073) c773_mtvec 0x000000008000006c
core   0: 3 0x000000008000000c (0x00001517) x10 0x000000008000100c
core   0: 3 0x0000000080000010 (0x1f450513) x10 0x0000000080001200
core   0: 3 0x0000000080000014 (0x003d2737) x14 0x00000000003d2000
core   0: 3 0x0000000080000018 (0xea97071b) x14 0x00000000003d1ea9
core   0: 3 0x000000008000001c (0x00c71713) x14 0x00000003d1ea9000
core   0: 3 0x0000000080000020 (0x5f770713) x14 0x00000003d1ea95f7
core   0: 3 0x0000000080000024 (0x00c71713) x14 0x00003d1ea95f7000
core   0: 3 0x0000000080000028 (0x2c170713) x14 0x00003d1ea95f72c1
core   0: 3 0x000000008000002c (0x01171713) x14 0x7a3d52bee5820000
core   0: 3 0x0000000080000030 (0xa7370713) x14 0x7a3d52bee581fa73
core   0: 3 0x0000000080000034 (0x0012a837) x16 0x000000000012a000
core   0: 3 0x0000000080000038 (0xf7f8081b) x16 0x0000000000129f7f
core   0: 3 0x000000008000003c (0x00e81813) x16 0x00000004a7dfc000
core   0: 3 0x0000000080000040 (0xaf980813) x16 0x00000004a7dfbaf9
core   0: 3 0x0000000080000044 (0x00f81813) x16 0x000253efdd7c8000
core   0: 3 0x0000000080000048 (0xd6b80813) x16 0x000253efdd7c7d6b
core   0: 3 0x000000008000004c (0x00c81813) x16 0x253efdd7c7d6b000
core   0: 3 0x0000000080000050 (0xe4280813) x16 0x253efdd7c7d6ae42
core   0: 3 0x0000000080000054 (0xb1070677) x12 0xffffffffaa7abba6
core   0: 3 0x0000000080000058 (0x00c53023) mem 0x0000000080001200 0xffffffffaa7abba6
core   0: 3 0x000000008000005c (0x00100193) x3  0x0000000000000001
core   0: 3 0x0000000080000060 (0x00001f17) x30 0x0000000080001060
core   0: 3 0x0000000080000064 (0xfa3f2023) mem 0x0000000080001000 0x00000001
core   0: 3 0x0000000080000068 (0x0000006f)

[eflaner]

@hope51607
I was able to reproduce on the branch which is 6 commits behind the current master., yet the commit log remains same as above.
Can you try the below command and see if you're getting a different execution values, for the same elf

spike --log-commits --isa=rv64ip +signature=spike.log tmpwg1k6zvu.elf signature-granularity=8 2> tmpwg1k6zvu.log

[scottj97]

@hope51607 it seems this discussion was left with some unanswered questions; can you please document here how you were finally able to recreate the issue?

[hope51607]

@scottj97 of course, below is how I recreate the issue.

I reproduced the problem on GCC version 6.4.0 20180424 (Ubuntu 6.4.0-17ubuntu1).
I pulled out the code and macro associated with umul16.
Then enable -fsanitize=undefined to find the issue.

[eflaner]

Fixed with #1053