BZHI panic at wrong bit_position

[phuclv90]

According to the doc bzhi will panic when

If bit_position >= bit_size() and -C debug-assertions=1.

However the behavior is actually defined for all bit_position <= 0xFF because in the instruction the INDEX (i.e bit_position) value is the low 8 bits of the 2nd source and "The INDEX value is saturated at the value of OperandSize -1" which means for INDEX >= OperandSize the destination register is unchanged. It's confirmed by the operation:

N ← SRC2[7:0]
DEST ← SRC1
IF (N < OperandSize)
    DEST[OperandSize-1:N] ← 0
FI
IF (N > OperandSize - 1)
    CF ← 1
ELSE
    CF ← 0
FI

As you can see, if N >= OperandSize nothing in the destination register is touched and there are no undefined states except for the AF and PF flags. The Chromium test suite also actually tests those large N values such as 64 or 257 The bit_position == bit_size() case is actually very useful to create a mask with N least significant bits set with N in [0, 64] range

So I think the behavior should be changed to panic if bit_position > 0xFF or if bit_position > bit_size() so it won't panic for the bit_position == bit_size() case

[bjorn3]

I think you should open an issue for https://github.com/gnzlbg/bitintr instead.

[tesuji]

I don't think gnzlbg does opensource anymore. But yeah, should be an issue for that repo.

[sayantn]

this doesn't seem related to this repo, bzhi_u{32,64} have the correct behavior on n>=SIZE, which is just return a unchanged (https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=bzhi&ig_expand=633)