Conflict between spec and GCC of bit manipulation instructions

Created by: melonedo

Take cv.bclr for example. The testcase cv-march-xcvbitmanip-compile-bclr.c has:

// source
// note that 200 == (6 << 5) + 8
  res1 = __builtin_riscv_cv_bitmanip_bclr (a, 200);
// check
/* { dg-final { scan-assembler-times "cv\.bclr\t\(\?\:t\[0-6\]\|a\[0-7\]\|s\[1-11\]\),\(\?\:t\[0-6\]\|a\[0-7\]\|s\[1-11\]\),6,8" 1 } } */

assumes the compiled instruction to be like cv.bclr a0, a1, 6, 8. That is, the lower 5 bits come after the higher 5 bits, or cv.bclr rD, rs1, range[9:5], range[4:0].

However in the OpenHW specification: CORE-V builtin names#PULP bit manipulation builtins (32-bit), the lower 5 bits come before the higher 5 bits:

uint32_t __builtin_riscv_cv_bitmanip_bclr (uint32_t i, uint16_t range)

Case a) range is a constant

result: rD

i: rs1

range[4:0]: Is2 (5-bit unsigned value)

range[9:5]: Is3 (5-bit unsigned value)

Generated assembler:

Case a)
        cv.bclr  rD,rs1,Is2,Is3

FYI, this could be due to a difference in the signature of cv.bclr, which is cv.bclr rD, rs1, Is3, Is2 in CORE-V Instruction Set Custom Extension#Bit Manipulation Operations where the order of Is3 and Is2 is reversed.