Repository: sabnzbd/sabctools (language: python)

Issue:
SBC with RISC-V & Vector 1.0: no commands starting with "v" (for vector?) in generated sabctools so library 
pinging @animetosho 

I received my "Banana Pi BPI-F3 SpacemiT K1 8 Core RISC-V", which should have risc-v vector 1.0 (aka RVV 1.0). Running Armbian Ubuntu noble on it.

After `python3 setup.py build`, I do not see commands starting with "v" (assumption: vector commands) in the objdump of the generated sabctools .so libary.

Wrong method? Wrong gcc? Wrong ... ?

Help appreciated. 



```
sander@bananapif3:~/git/sabctools$ objdump -d build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so | awk '{ print $3 }'  | sort | grep -E ^v
sander@bananapif3:~/git/sabctools$ 
```

```
sander@bananapif3:~/git/sabctools$ file build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so
build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so: ELF 64-bit LSB shared object, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), dynamically linked, BuildID[sha1]=315e5cdf08195349ab78d64a00efffdb9443c8ac, with debug_info, not stripped
```

System info:

```
sander@bananapif3:~/git/sabctools$ gcc --version
gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```




```
sander@bananapif3:~/git/sabctools$ uname -a
Linux bananapif3 6.1.15-legacy-k1 #2 SMP PREEMPT Wed May  1 14:17:59 UTC 2024 riscv64 riscv64 riscv64 GNU/Linux
sander@bananapif3:~/git/sabctools$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Armbian-bpi-SpacemiT 24.5.0-trunk noble
Release:	24.04
Codename:	noble
sander@bananapif3:~/git/sabctools$ 
sander@bananapif3:~/git/sabctools$ cat /proc/cpuinfo 
processor	: 0
hart		: 0
model name	: Spacemit(R) X60
isa		: rv64imafdcv_sscofpmf_sstc_svpbmt_zicbom_zicboz_zicbop_zihintpause
mmu		: sv39
mvendorid	: 0x710
marchid		: 0x8000000058000001
mimpid		: 0x1000000049772200



```


```
sander@bananapif3:~/git/sabctools$ git log --oneline | head -8
c085cb1 Release v8.2.0
b1e86cc Bump pypa/cibuildwheel from 2.17.0 to 2.18.0 (#115)
04386bd Update yEnc module to rapidyenc 1.1.1 (#114)
3ed5229 Correct building on macOS-latest
b2ea288 Bump pypa/cibuildwheel from 2.16.5 to 2.17.0 (#113)
c7e6891 Bump pypa/cibuildwheel from 2.16.4 to 2.16.5 (#112)
b206964 Bump pypa/cibuildwheel from 2.16.2 to 2.16.4 (#111)
59306c5 Correct publish action steps
```

Update yEnc module
This brings the yEnc code up to date with rapidyenc v1.1.1, and removes almost all sabctools' specific modifications (should allow easier updates in future).

## Key changes

* add AVX10 and experimental RISC-V Vector/crypto support
* add faster baseline CRC32 implementation (though crcutil still seems to be faster on older x86 processors)
* add platform optimised CRC manipulation routines, replacing such functionality from crcutil
  * this allows rapidyenc to optionally be built without crcutil
* avoid a performance pitfall on Zen4 processors
* officially support decoding where destination/source buffer are the same
  * fixes a rare bug with this setup, which could cause the end to be mis-detected
* de-dupe some code/lookup tables for a slight reduction in binary size

## Possible future changes

* I don't think [the `UNSUPPORTED_PLATFORM_ARM` check](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/setup.py#L127-L133) is relevant any more, as the code itself checks for the header, but [it's left in](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/src/yencode/common.h#L37-L39) as it might need some testing (this is the only remaining sabctools specific modification to rapidyenc)
* this PR redirects sabctools to use the new CRC functions, although I've kept crcutil present. If desired, crcutil can be disabled for a smaller build
* rapidyenc can now be built without the encoder, though sabctools does use it (only for testing I believe)
* there are [CRC32 tests where the CRC32 exceeds 32 bits](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/tests/test_crc32.py#L13-L14). I'm not sure of the purpose of these tests (they don't appear to be related to #96), but I've left them in, except for a problematic one
Update yEnc module
This brings the yEnc code up to date with rapidyenc v1.1.1, and removes almost all sabctools' specific modifications (should allow easier updates in future).

## Key changes

* add AVX10 and experimental RISC-V Vector/crypto support
* add faster baseline CRC32 implementation (though crcutil still seems to be faster on older x86 processors)
* add platform optimised CRC manipulation routines, replacing such functionality from crcutil
  * this allows rapidyenc to optionally be built without crcutil
* avoid a performance pitfall on Zen4 processors
* officially support decoding where destination/source buffer are the same
  * fixes a rare bug with this setup, which could cause the end to be mis-detected
* de-dupe some code/lookup tables for a slight reduction in binary size

## Possible future changes

* I don't think [the `UNSUPPORTED_PLATFORM_ARM` check](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/setup.py#L127-L133) is relevant any more, as the code itself checks for the header, but [it's left in](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/src/yencode/common.h#L37-L39) as it might need some testing (this is the only remaining sabctools specific modification to rapidyenc)
* this PR redirects sabctools to use the new CRC functions, although I've kept crcutil present. If desired, crcutil can be disabled for a smaller build
* rapidyenc can now be built without the encoder, though sabctools does use it (only for testing I believe)
* there are [CRC32 tests where the CRC32 exceeds 32 bits](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/tests/test_crc32.py#L13-L14). I'm not sure of the purpose of these tests (they don't appear to be related to #96), but I've left them in, except for a problematic one
Update yEnc module
This brings the yEnc code up to date with rapidyenc v1.1.1, and removes almost all sabctools' specific modifications (should allow easier updates in future).

## Key changes

* add AVX10 and experimental RISC-V Vector/crypto support
* add faster baseline CRC32 implementation (though crcutil still seems to be faster on older x86 processors)
* add platform optimised CRC manipulation routines, replacing such functionality from crcutil
  * this allows rapidyenc to optionally be built without crcutil
* avoid a performance pitfall on Zen4 processors
* officially support decoding where destination/source buffer are the same
  * fixes a rare bug with this setup, which could cause the end to be mis-detected
* de-dupe some code/lookup tables for a slight reduction in binary size

## Possible future changes

* I don't think [the `UNSUPPORTED_PLATFORM_ARM` check](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/setup.py#L127-L133) is relevant any more, as the code itself checks for the header, but [it's left in](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/src/yencode/common.h#L37-L39) as it might need some testing (this is the only remaining sabctools specific modification to rapidyenc)
* this PR redirects sabctools to use the new CRC functions, although I've kept crcutil present. If desired, crcutil can be disabled for a smaller build
* rapidyenc can now be built without the encoder, though sabctools does use it (only for testing I believe)
* there are [CRC32 tests where the CRC32 exceeds 32 bits](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/tests/test_crc32.py#L13-L14). I'm not sure of the purpose of these tests (they don't appear to be related to #96), but I've left them in, except for a problematic one


Discussion / hints:
You generally want to be running bleeding edge for RISC-V, so try upgrading to GCC 14. GCC 13 lacks typecast intrinsics, so it's [explicitly disabled](https://github.com/sabnzbd/sabctools/blob/c085cb122e2bee3c81ba8427b62fa06264ae6ff7/src/yencode/common.h#L306-L308) there.

Clang 14+ should also work.
I installed gcc-14 etc, made it active, did the build, but still no commands starting with "v" in the objdump-disassembly.

So can you help further?
And: the objdump method: is that correct, and does it give v-commands in your output?

Installed gcc-14:
```
sudo apt install gcc-14 g++-14
```
via update-alternatives set gcc-14 etc to active:
```
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-14 90 --slave /usr/bin/g++ g++ /usr/bin/g++-14 --slave /usr/bin/gcov gcov /usr/bin/gcov-14 --slave /usr/bin/riscv64-linux-gnu-gcc riscv64-linux-gnu-gcc /usr/bin/riscv64-linux-gnu-gcc-14

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-13 70 --slave /usr/bin/g++ g++ /usr/bin/g++-13 --slave /usr/bin/gcov gcov /usr/bin/gcov-13 --slave /usr/bin/riscv64-linux-gnu-gcc  riscv64-linux-gnu-gcc /usr/bin/riscv64-linux-gnu-gcc-13
```

Checking ... looks good ... version 14 is now default:

```
sander@bananapif3:~/git/sabctools$ riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (Ubuntu 14-20240412-0ubuntu1) 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


sander@bananapif3:~/git/sabctools$ which  riscv64-linux-gnu-gcc
/usr/bin/riscv64-linux-gnu-gcc
sander@bananapif3:~/git/sabctools$ ll /usr/bin/riscv64-linux-gnu-gcc
lrwxrwxrwx 1 root root 39 May 17 15:10 /usr/bin/riscv64-linux-gnu-gcc -> /etc/alternatives/riscv64-linux-gnu-gcc*
sander@bananapif3:~/git/sabctools$ ll /etc/alternatives/riscv64-linux-gnu-gcc
lrwxrwxrwx 1 root root 33 Apr 12 14:30 /etc/alternatives/riscv64-linux-gnu-gcc -> /usr/bin/riscv64-linux-gnu-gcc-14*
```


clean & build:
```
python3 setup.py clean
python3 setup.py build

```
Check: yes, freshly built:

```
sander@bananapif3:~/git/sabctools$ ll build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so
-rwxrwxr-x 1 sander sander 385656 May 17 15:11 build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so*
```

... but still no commands starting with "v" in the disassembled code:

```
objdump -d  build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so  | awk '{ print $3 }'  | sort -u | grep -E "^v"
```
Proof the objdump does disassemble:

```
sander@bananapif3:~/git/sabctools$ objdump -d  build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so  | awk '{ print $3 }'  | sort -u | head

add
addi
addiw
addw
and
andi
auipc
beq
beqz
sander@bananapif3:~/git/sabctools$ objdump -d  build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so  | awk '{ print $3 }'  | sort -u | tail
srai
sraiw
srl
srli
srliw
sub
subw
sw
xor
zext.b
```

Thanks for trying that out.

> And: the objdump method: is that correct, and does it give v-commands in your output?

That should be a sufficient indicator.

Are you able to check what commands are being passed to the compiler exactly? Not sure if setuptools offers the option by default.

You can also try with [rapidyenc](https://github.com/animetosho/rapidyenc) directly - this should help isolate whether the build config has an issue.  
If you try rapidyenc directly, after the `cmake ..` command, you can use `make VERBOSE=1` which should show the commands being executed. In the list, the de/encoder_rvv files [should have](https://github.com/animetosho/rapidyenc/blob/1481b66739bbf075242b92e1ca3515f30ac8a337/CMakeLists.txt#L227-L228) the `-march=rv64gcv` option set.
You should also be able to see `==> Checking support for flag: -march=rv64gcv` in the build log for sabctools.  
If using pip to install/build, it seems like passing the `-v` option will display all issued commands. Look at the commands used to build *decoder_rvv.cc*

My attempt to cross build isn't working due to setuptools sending flags the compiler doesn't like.
```
sander@bananapif3:~/git/sabctools$ git pull
Already up to date.

sander@bananapif3:~/git/sabctools$ python3 setup.py clean
running clean
removing 'build/temp.linux-riscv64-cpython-312' (and everything under it)

sander@bananapif3:~/git/sabctools$ 
sander@bananapif3:~/git/sabctools$ 
sander@bananapif3:~/git/sabctools$ python3 setup.py build
running build
running build_py
running build_ext
==> Baseline detection: ARM=False, x86=False, macOS=False
==> Checking support for flag: -std=c++11
==> Please ignore any errors shown below!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c /tmp/tmp28dpejbi.cc -o tmp/tmp28dpejbi.o -std=c++11
==> Success!
==> Checking support for flag: -march=rv64gcv
==> Please ignore any errors shown below!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c /tmp/tmpczvs55v1.cc -o tmp/tmpczvs55v1.o -march=rv64gcv
==> Success!
==> Checking support for flag: -march=rv64gc_zbkc
==> Please ignore any errors shown below!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c /tmp/tmp5tjjbe6o.cc -o tmp/tmp5tjjbe6o.o -march=rv64gc_zbkc
==> Success!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/platform.cc -o build/src/yencode/platform.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/encoder.cc -o build/src/yencode/encoder.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/decoder.cc -o build/src/yencode/decoder.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/crc.cc -o build/src/yencode/crc.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_sse2.cc -o build/src/yencode/encoder_sse2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_sse2.cc -o build/src/yencode/decoder_sse2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_ssse3.cc -o build/src/yencode/encoder_ssse3.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_ssse3.cc -o build/src/yencode/decoder_ssse3.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_folding.cc -o build/src/yencode/crc_folding.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_folding_256.cc -o build/src/yencode/crc_folding_256.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_avx.cc -o build/src/yencode/encoder_avx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_avx.cc -o build/src/yencode/decoder_avx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_avx2.cc -o build/src/yencode/encoder_avx2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_avx2.cc -o build/src/yencode/decoder_avx2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_vbmi2.cc -o build/src/yencode/encoder_vbmi2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_vbmi2.cc -o build/src/yencode/decoder_vbmi2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_neon.cc -o build/src/yencode/encoder_neon.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_neon64.cc -o build/src/yencode/decoder_neon64.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_arm.cc -o build/src/yencode/crc_arm.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_arm_pmull.cc -o build/src/yencode/crc_arm_pmull.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_rvv.cc -o build/src/yencode/encoder_rvv.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_rvv.cc -o build/src/yencode/decoder_rvv.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_riscv.cc -o build/src/yencode/crc_riscv.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/crc32c_sse4.cc -o build/src/crcutil-1.0/code/crc32c_sse4.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.cc -o build/src/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.cc -o build/src/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.cc -o build/src/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.cc -o build/src/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.cc -o build/src/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/examples/interface.cc -o build/src/crcutil-1.0/examples/interface.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yenc.cc -o build/src/yenc.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/unlocked_ssl.cc -o build/src/unlocked_ssl.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter -Wno-missing-field-initializers
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/crc32.cc -o build/src/crc32.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/sparse.cc -o build/src/sparse.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/utils.cc -o build/src/utils.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
building 'sabctools.sabctools' extension
creating build/temp.linux-riscv64-cpython-312
creating build/temp.linux-riscv64-cpython-312/src
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/sabctools.cc -o build/temp.linux-riscv64-cpython-312/src/sabctools.o -std=c++11
riscv64-linux-gnu-g++ -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-riscv64-cpython-312/src/sabctools.o -L/usr/lib/riscv64-linux-gnu -o build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so -ldl build/src/yencode/platform.o build/src/yencode/encoder.o build/src/yencode/decoder.o build/src/yencode/crc.o build/src/yencode/encoder_sse2.o build/src/yencode/decoder_sse2.o build/src/yencode/encoder_ssse3.o build/src/yencode/decoder_ssse3.o build/src/yencode/crc_folding.o build/src/yencode/crc_folding_256.o build/src/yencode/encoder_avx.o build/src/yencode/decoder_avx.o build/src/yencode/encoder_avx2.o build/src/yencode/decoder_avx2.o build/src/yencode/encoder_vbmi2.o build/src/yencode/decoder_vbmi2.o build/src/yencode/encoder_neon.o build/src/yencode/decoder_neon64.o build/src/yencode/crc_arm.o build/src/yencode/crc_arm_pmull.o build/src/yencode/encoder_rvv.o build/src/yencode/decoder_rvv.o build/src/yencode/crc_riscv.o build/src/crcutil-1.0/code/crc32c_sse4.o build/src/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o build/src/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o build/src/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o build/src/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.o build/src/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.o build/src/crcutil-1.0/examples/interface.o build/src/yenc.o build/src/unlocked_ssl.o build/src/crc32.o build/src/sparse.o build/src/utils.o
sander@bananapif3:~/git/sabctools$ 
```
> My attempt to cross build isn't working due to setuptools sending flags the compiler doesn't like.

I can give you ssh access to my RVV 1.0 hardware. Preferably via IPv6, as I'm behind IPV4-CGNAT.

And if you want, I can give you root access. The system is 2 days old, so clean, and I can reflash/reinstall if things go wrong.


Ah, progress ... via an ugly hack: forcing "-march=rv64gcv" as cflags in setup.py:

```
sander@bananapif3:~/git/sabctools$ diff setup.py.ORG setup.py
123a124,125
>             cflags.append("-march=rv64gcv") # Sander hack
> 
```

... and ... bingo ... v-commands in the resulting sabctools .so.

So detecting or setting `-march=rv64gcv `is not going well in the non-hacked setup.py?

```
sander@bananapif3:~/git/sabctools$ objdump -d build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so | awk '{ print $3 }' | sort -u | grep -E "^v" | head -20
vadd.vi
vadd.vv
vand.vi
vcompress.vm
vcpop.m
vid.v
viota.m
vle64.v
vle8.v
vmadc.vi
vmadc.vv
vmand.mm
vmandn.mm
vmerge.vxm
vmnor.mm
vmnot.m
vmor.mm
vmsbf.m
vmseq.vi
vmseq.vv
```


Ah, I think I messed some code in setup.py. Could you try replacing all instances of `gcc_rv_flags` with `gcc_flags` in that file, and try again?
> Could you try replacing all instances of `gcc_rv_flags` with `gcc_flags` in that file, and try again?

Bingo! The resulting .so contains v-commands! And compiling is now a normal time (1 minute), not 3+ minutes like with my ugly hack (where each compile line had that option forced in).


`$ sed -i -e 's/gcc_rv_flags/gcc_flags/g'  setup.py
`
Looks good:

```
sander@bananapif3:~/git/sabctools$ diff setup.py.ORG setup.py
291c291
<                 "gcc_rv_flags": gcc_rvv_flags,
---
>                 "gcc_flags": gcc_rvv_flags,
296c296
<                 "gcc_rv_flags": gcc_rvzbkc_flags,
---
>                 "gcc_flags": gcc_rvzbkc_flags,
```
**WAIT**: gcc_rvv_flags (double v) should still be there? It works, so looks good, but just checking ...

```
sander@bananapif3:~/git/sabctools$ objdump -d build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so | awk '{ print $3 }' | sort -u | grep -E "^v" | head -10
vadd.vi
vadd.vv
vcompress.vm
vcpop.m
viota.m
vle8.v
vmadc.vi
vmadc.vv
vmand.mm
vmandn.mm
```


```
sander@bananapif3:~/git/sabctools$ time python3 setup.py build
running build
running build_py
running build_ext
==> Baseline detection: ARM=False, x86=False, macOS=False
==> Checking support for flag: -std=c++11
==> Please ignore any errors shown below!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c /tmp/tmpp4bp8htk.cc -o tmp/tmpp4bp8htk.o -std=c++11
==> Success!
==> Checking support for flag: -march=rv64gcv
==> Please ignore any errors shown below!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c /tmp/tmpx80zysr5.cc -o tmp/tmpx80zysr5.o -march=rv64gcv
==> Success!
==> Checking support for flag: -march=rv64gc_zbkc
==> Please ignore any errors shown below!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c /tmp/tmpf8z0mjzf.cc -o tmp/tmpf8z0mjzf.o -march=rv64gc_zbkc
==> Success!
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/platform.cc -o build/src/yencode/platform.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/encoder.cc -o build/src/yencode/encoder.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/decoder.cc -o build/src/yencode/decoder.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/yencode/crc.cc -o build/src/yencode/crc.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_sse2.cc -o build/src/yencode/encoder_sse2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_sse2.cc -o build/src/yencode/decoder_sse2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_ssse3.cc -o build/src/yencode/encoder_ssse3.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_ssse3.cc -o build/src/yencode/decoder_ssse3.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_folding.cc -o build/src/yencode/crc_folding.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_folding_256.cc -o build/src/yencode/crc_folding_256.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_avx.cc -o build/src/yencode/encoder_avx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_avx.cc -o build/src/yencode/decoder_avx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_avx2.cc -o build/src/yencode/encoder_avx2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_avx2.cc -o build/src/yencode/decoder_avx2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_vbmi2.cc -o build/src/yencode/encoder_vbmi2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_vbmi2.cc -o build/src/yencode/decoder_vbmi2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_neon.cc -o build/src/yencode/encoder_neon.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_neon64.cc -o build/src/yencode/decoder_neon64.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_arm.cc -o build/src/yencode/crc_arm.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_arm_pmull.cc -o build/src/yencode/crc_arm_pmull.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/encoder_rvv.cc -o build/src/yencode/encoder_rvv.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -march=rv64gcv
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/decoder_rvv.cc -o build/src/yencode/decoder_rvv.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -march=rv64gcv
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yencode/crc_riscv.cc -o build/src/yencode/crc_riscv.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -march=rv64gc_zbkc
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/crc32c_sse4.cc -o build/src/crcutil-1.0/code/crc32c_sse4.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.cc -o build/src/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.cc -o build/src/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.cc -o build/src/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.cc -o build/src/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.cc -o build/src/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DCRCUTIL_USE_MM_CRC32=0 -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/tests -I/usr/include/python3.12 -c src/crcutil-1.0/examples/interface.cc -o build/src/crcutil-1.0/examples/interface.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-expansion-to-defined -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/yenc.cc -o build/src/yenc.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/unlocked_ssl.cc -o build/src/unlocked_ssl.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter -Wno-missing-field-initializers
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -Isrc/crcutil-1.0/code -Isrc/crcutil-1.0/examples -I/usr/include/python3.12 -c src/crc32.cc -o build/src/crc32.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/sparse.cc -o build/src/sparse.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/utils.cc -o build/src/utils.o -Wall -Wextra -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -O3 -fPIC -fwrapv -std=c++11 -Wno-unused-parameter
building 'sabctools.sabctools' extension
creating build/temp.linux-riscv64-cpython-312
creating build/temp.linux-riscv64-cpython-312/src
riscv64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/usr/include/python3.12 -c src/sabctools.cc -o build/temp.linux-riscv64-cpython-312/src/sabctools.o -std=c++11
riscv64-linux-gnu-g++ -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-riscv64-cpython-312/src/sabctools.o -L/usr/lib/riscv64-linux-gnu -o build/lib.linux-riscv64-cpython-312/sabctools/sabctools.cpython-312-riscv64-linux-gnu.so -ldl build/src/yencode/platform.o build/src/yencode/encoder.o build/src/yencode/decoder.o build/src/yencode/crc.o build/src/yencode/encoder_sse2.o build/src/yencode/decoder_sse2.o build/src/yencode/encoder_ssse3.o build/src/yencode/decoder_ssse3.o build/src/yencode/crc_folding.o build/src/yencode/crc_folding_256.o build/src/yencode/encoder_avx.o build/src/yencode/decoder_avx.o build/src/yencode/encoder_avx2.o build/src/yencode/decoder_avx2.o build/src/yencode/encoder_vbmi2.o build/src/yencode/decoder_vbmi2.o build/src/yencode/encoder_neon.o build/src/yencode/decoder_neon64.o build/src/yencode/crc_arm.o build/src/yencode/crc_arm_pmull.o build/src/yencode/encoder_rvv.o build/src/yencode/decoder_rvv.o build/src/yencode/crc_riscv.o build/src/crcutil-1.0/code/crc32c_sse4.o build/src/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.o build/src/crcutil-1.0/code/multiword_64_64_gcc_amd64_asm.o build/src/crcutil-1.0/code/multiword_64_64_gcc_i386_mmx.o build/src/crcutil-1.0/code/multiword_64_64_intrinsic_i386_mmx.o build/src/crcutil-1.0/code/multiword_128_64_gcc_amd64_sse2.o build/src/crcutil-1.0/examples/interface.o build/src/yenc.o build/src/unlocked_ssl.o build/src/crc32.o build/src/sparse.o build/src/utils.o

real	1m3.101s
user	0m59.747s
sys	0m3.330s

```




> experimental RISC-V Vector/crypto support

Wow! That is based on RV1.0? How did you test? On a virtual RISC-V RV1 machine?

If so, time for me to buy a newer RISC-V SBC; my current one support RV0.7.x

> Wow! That is based on RV1.0? How did you test? On a virtual RISC-V RV1 machine?

Yes. GCC 14 might be able to compile it for 0.7.1, but I don't know if it works as I'm only really supporting 1.0.  
Actually, the feature detection doesn't seem to offer the ability to query the version, so I wonder how it'd work on a draft-spec CPU.

I don't have any hardware, so I tested it via qemu\*. No clue what actual performance is like (and even if I had hardware, RVV is, let's just say, rather liberal in what hardware is allowed to do, which makes it a little tricky to predict performance in a general sense).

\* I've only tested the yEnc code itself, not sabctools

---

The build failures seem to be failing at upgrading pip, which shouldn't be affected by this PR. Not sure what the correct fix is.
> I don't have any hardware

Well ... because you made the RV1.0 code ... I ordered RV1.0 hardware: "Banana Pi BPI-F3 SpacemiT K1 8 Core RISC-V chip".  To arrive at end of May.
The code changes are beyond my understanding, but do I understand correctly that crcutil is never used anymore? Even not as a fallback? Only if specifically enabled by compiler flag? Then indeed we can just remove it fully.

The crc32 exceeding 32bit, wasn't that for either the 32bit arm platforms or that exotic 32bit on 64bit platform that Linux supports?

The unsupported arm flag was for an old Synology chip, but I think we dropped that one already because unrar doesn't support old arm anymore. Will have to check that.
> but do I understand correctly that crcutil is never used anymore? Even not as a fallback? Only if specifically enabled by compiler flag?

It's still enabled by default, but only used on x86 CPUs which don't support PCLMULQDQ (which are quite old at this stage). There, the crcutil code is slightly faster than the fallback CRC code I have (e.g. 1150.71 vs 1325.75 MB/s on a Xeon L3426).  
On the stripped rapidyenc shared Linux binary, removing crcutil saves around 60KB (and maybe makes builds a little faster).

> The crc32 exceeding 32bit, wasn't that for either the 32bit arm platforms or that exotic 32bit on 64bit platform that Linux supports?

That doesn't quite sound right, as they should have no issue with sticking to 32-bit.  
My guess is that the crcutil interface took in 64-bit integers (since it was a generic CRC implementation, instead of being specific to CRC32), so it just got parsed as such. And because of that, the limits got tested that way.

> there are [CRC32 tests where the CRC32 exceeds 32 bits](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/tests/test_crc32.py#L13-L14). I'm not sure of the purpose of these tests (they don't appear to be related to [Incorrect CRC32 failure #96](https://github.com/sabnzbd/sabctools/issues/96)), but I've left them in, except for a problematic one

There is a bit of discussion around that in https://github.com/sabnzbd/sabctools/pull/80#issuecomment-1396275556 looks like an extreme case since Python would let you pass huge values and I think crcutil wouldn't handle them as expected. I believe we resolved to just disregard >32 bits.

---

Test failures are because macos-latest runner is an M1 (macos-14-arm64) then I think it tries to run x64 Python.
It should just need updating to use a x64 runner, and could have seperate arm64 added.



> It's still enabled by default, but only used on x86 CPUs which don't support PCLMULQDQ (which are quite old at this stage). There, the crcutil code is slightly faster than the fallback CRC code I have (e.g. 1150.71 vs 1325.75 MB/s on a Xeon L3426).

Seems like such a small benefit that we could just drop crcutil?
Or you still use it in rapidyenc also? Then we can keep it, just to keep things as similar as possible for easy future updates.
> There is a bit of discussion around that in #80 (comment) looks like an extreme case since Python would let you pass huge values and I think crcutil wouldn't handle them as expected. I believe we resolved to just disregard >32 bits.

I think that was for the length as opposed to the CRC32 itself?  
I did add tests to check the extremities of 64-bit lengths, since the new code does handle the full range correctly.

I suppose it doesn't matter much, but perhaps the tests involving >32-bit CRC32s can be removed, as they're not really a valid scenario.

> Test failures are because macos-latest runner is an M1 (macos-14-arm64)

Ooh, that's interesting. I've never been able to test anything on ARM Mac, so that could be useful if Github supports it now.

> Or you still use it in rapidyenc also? Then we can keep it, just to keep things as similar as possible for easy future updates.

I've left it enabled by default because it is technically faster and I don't really mind the size cost, but I support a build flag to disable it.  
If the size cost isn't a concern for you, it probably makes sense to keep it for now.
I fixed the macOS runs on the main branch by simply not forcing the architecture, only for the 32bit Windows build.

Thanks a lot for the update :)
> experimental RISC-V Vector/crypto support

Wow! That is based on RV1.0? How did you test? On a virtual RISC-V RV1 machine?

If so, time for me to buy a newer RISC-V SBC; my current one support RV0.7.x

> Wow! That is based on RV1.0? How did you test? On a virtual RISC-V RV1 machine?

Yes. GCC 14 might be able to compile it for 0.7.1, but I don't know if it works as I'm only really supporting 1.0.  
Actually, the feature detection doesn't seem to offer the ability to query the version, so I wonder how it'd work on a draft-spec CPU.

I don't have any hardware, so I tested it via qemu\*. No clue what actual performance is like (and even if I had hardware, RVV is, let's just say, rather liberal in what hardware is allowed to do, which makes it a little tricky to predict performance in a general sense).

\* I've only tested the yEnc code itself, not sabctools

---

The build failures seem to be failing at upgrading pip, which shouldn't be affected by this PR. Not sure what the correct fix is.
> I don't have any hardware

Well ... because you made the RV1.0 code ... I ordered RV1.0 hardware: "Banana Pi BPI-F3 SpacemiT K1 8 Core RISC-V chip".  To arrive at end of May.
The code changes are beyond my understanding, but do I understand correctly that crcutil is never used anymore? Even not as a fallback? Only if specifically enabled by compiler flag? Then indeed we can just remove it fully.

The crc32 exceeding 32bit, wasn't that for either the 32bit arm platforms or that exotic 32bit on 64bit platform that Linux supports?

The unsupported arm flag was for an old Synology chip, but I think we dropped that one already because unrar doesn't support old arm anymore. Will have to check that.
> but do I understand correctly that crcutil is never used anymore? Even not as a fallback? Only if specifically enabled by compiler flag?

It's still enabled by default, but only used on x86 CPUs which don't support PCLMULQDQ (which are quite old at this stage). There, the crcutil code is slightly faster than the fallback CRC code I have (e.g. 1150.71 vs 1325.75 MB/s on a Xeon L3426).  
On the stripped rapidyenc shared Linux binary, removing crcutil saves around 60KB (and maybe makes builds a little faster).

> The crc32 exceeding 32bit, wasn't that for either the 32bit arm platforms or that exotic 32bit on 64bit platform that Linux supports?

That doesn't quite sound right, as they should have no issue with sticking to 32-bit.  
My guess is that the crcutil interface took in 64-bit integers (since it was a generic CRC implementation, instead of being specific to CRC32), so it just got parsed as such. And because of that, the limits got tested that way.

> there are [CRC32 tests where the CRC32 exceeds 32 bits](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/tests/test_crc32.py#L13-L14). I'm not sure of the purpose of these tests (they don't appear to be related to [Incorrect CRC32 failure #96](https://github.com/sabnzbd/sabctools/issues/96)), but I've left them in, except for a problematic one

There is a bit of discussion around that in https://github.com/sabnzbd/sabctools/pull/80#issuecomment-1396275556 looks like an extreme case since Python would let you pass huge values and I think crcutil wouldn't handle them as expected. I believe we resolved to just disregard >32 bits.

---

Test failures are because macos-latest runner is an M1 (macos-14-arm64) then I think it tries to run x64 Python.
It should just need updating to use a x64 runner, and could have seperate arm64 added.



> It's still enabled by default, but only used on x86 CPUs which don't support PCLMULQDQ (which are quite old at this stage). There, the crcutil code is slightly faster than the fallback CRC code I have (e.g. 1150.71 vs 1325.75 MB/s on a Xeon L3426).

Seems like such a small benefit that we could just drop crcutil?
Or you still use it in rapidyenc also? Then we can keep it, just to keep things as similar as possible for easy future updates.
> There is a bit of discussion around that in #80 (comment) looks like an extreme case since Python would let you pass huge values and I think crcutil wouldn't handle them as expected. I believe we resolved to just disregard >32 bits.

I think that was for the length as opposed to the CRC32 itself?  
I did add tests to check the extremities of 64-bit lengths, since the new code does handle the full range correctly.

I suppose it doesn't matter much, but perhaps the tests involving >32-bit CRC32s can be removed, as they're not really a valid scenario.

> Test failures are because macos-latest runner is an M1 (macos-14-arm64)

Ooh, that's interesting. I've never been able to test anything on ARM Mac, so that could be useful if Github supports it now.

> Or you still use it in rapidyenc also? Then we can keep it, just to keep things as similar as possible for easy future updates.

I've left it enabled by default because it is technically faster and I don't really mind the size cost, but I support a build flag to disable it.  
If the size cost isn't a concern for you, it probably makes sense to keep it for now.
I fixed the macOS runs on the main branch by simply not forcing the architecture, only for the 32bit Windows build.

Thanks a lot for the update :)
> experimental RISC-V Vector/crypto support

Wow! That is based on RV1.0? How did you test? On a virtual RISC-V RV1 machine?

If so, time for me to buy a newer RISC-V SBC; my current one support RV0.7.x

> Wow! That is based on RV1.0? How did you test? On a virtual RISC-V RV1 machine?

Yes. GCC 14 might be able to compile it for 0.7.1, but I don't know if it works as I'm only really supporting 1.0.  
Actually, the feature detection doesn't seem to offer the ability to query the version, so I wonder how it'd work on a draft-spec CPU.

I don't have any hardware, so I tested it via qemu\*. No clue what actual performance is like (and even if I had hardware, RVV is, let's just say, rather liberal in what hardware is allowed to do, which makes it a little tricky to predict performance in a general sense).

\* I've only tested the yEnc code itself, not sabctools

---

The build failures seem to be failing at upgrading pip, which shouldn't be affected by this PR. Not sure what the correct fix is.
> I don't have any hardware

Well ... because you made the RV1.0 code ... I ordered RV1.0 hardware: "Banana Pi BPI-F3 SpacemiT K1 8 Core RISC-V chip".  To arrive at end of May.
The code changes are beyond my understanding, but do I understand correctly that crcutil is never used anymore? Even not as a fallback? Only if specifically enabled by compiler flag? Then indeed we can just remove it fully.

The crc32 exceeding 32bit, wasn't that for either the 32bit arm platforms or that exotic 32bit on 64bit platform that Linux supports?

The unsupported arm flag was for an old Synology chip, but I think we dropped that one already because unrar doesn't support old arm anymore. Will have to check that.
> but do I understand correctly that crcutil is never used anymore? Even not as a fallback? Only if specifically enabled by compiler flag?

It's still enabled by default, but only used on x86 CPUs which don't support PCLMULQDQ (which are quite old at this stage). There, the crcutil code is slightly faster than the fallback CRC code I have (e.g. 1150.71 vs 1325.75 MB/s on a Xeon L3426).  
On the stripped rapidyenc shared Linux binary, removing crcutil saves around 60KB (and maybe makes builds a little faster).

> The crc32 exceeding 32bit, wasn't that for either the 32bit arm platforms or that exotic 32bit on 64bit platform that Linux supports?

That doesn't quite sound right, as they should have no issue with sticking to 32-bit.  
My guess is that the crcutil interface took in 64-bit integers (since it was a generic CRC implementation, instead of being specific to CRC32), so it just got parsed as such. And because of that, the limits got tested that way.

> there are [CRC32 tests where the CRC32 exceeds 32 bits](https://github.com/animetosho/sabctools/blob/088ee38fc6d0894551b12d1b04477ff226bd1581/tests/test_crc32.py#L13-L14). I'm not sure of the purpose of these tests (they don't appear to be related to [Incorrect CRC32 failure #96](https://github.com/sabnzbd/sabctools/issues/96)), but I've left them in, except for a problematic one

There is a bit of discussion around that in https://github.com/sabnzbd/sabctools/pull/80#issuecomment-1396275556 looks like an extreme case since Python would let you pass huge values and I think crcutil wouldn't handle them as expected. I believe we resolved to just disregard >32 bits.

---

Test failures are because macos-latest runner is an M1 (macos-14-arm64) then I think it tries to run x64 Python.
It should just need updating to use a x64 runner, and could have seperate arm64 added.



> It's still enabled by default, but only used on x86 CPUs which don't support PCLMULQDQ (which are quite old at this stage). There, the crcutil code is slightly faster than the fallback CRC code I have (e.g. 1150.71 vs 1325.75 MB/s on a Xeon L3426).

Seems like such a small benefit that we could just drop crcutil?
Or you still use it in rapidyenc also? Then we can keep it, just to keep things as similar as possible for easy future updates.
> There is a bit of discussion around that in #80 (comment) looks like an extreme case since Python would let you pass huge values and I think crcutil wouldn't handle them as expected. I believe we resolved to just disregard >32 bits.

I think that was for the length as opposed to the CRC32 itself?  
I did add tests to check the extremities of 64-bit lengths, since the new code does handle the full range correctly.

I suppose it doesn't matter much, but perhaps the tests involving >32-bit CRC32s can be removed, as they're not really a valid scenario.

> Test failures are because macos-latest runner is an M1 (macos-14-arm64)

Ooh, that's interesting. I've never been able to test anything on ARM Mac, so that could be useful if Github supports it now.

> Or you still use it in rapidyenc also? Then we can keep it, just to keep things as similar as possible for easy future updates.

I've left it enabled by default because it is technically faster and I don't really mind the size cost, but I support a build flag to disable it.  
If the size cost isn't a concern for you, it probably makes sense to keep it for now.
I fixed the macOS runs on the main branch by simply not forcing the architecture, only for the 32bit Windows build.

Thanks a lot for the update :)

Fix patch:
diff --git a/setup.py b/setup.py
index d00f9d5..13d847e 100644
--- a/setup.py
+++ b/setup.py
@@ -124,13 +124,6 @@ def build_extension(self, ext: Extension):
             # Verify specific flags for ARM chips
             # macOS M1 do not need any flags, they support everything
             if IS_ARM and not IS_MACOS:
-                if not autoconf_check(self.compiler, include_check="sys/auxv.h"):
-                    # We only tested this for GCC, might still be valid on MS-ARM compiler (see #38)
-                    if autoconf_check(self.compiler, define_check="__GNUC__"):
-                        log.info("==> On GGC and sys/auxv.h not available, setting UNSUPPORTED_PLATFORM_ARM=1")
-                        ext.define_macros.append(("UNSUPPORTED_PLATFORM_ARM", "1"))
-                        gcc_macros.append(("UNSUPPORTED_PLATFORM_ARM", "1"))
-                        IS_ARM = False
                 if not autoconf_check(self.compiler, define_check="__aarch64__"):
                     log.info("==> __aarch64__ not available, disabling 64bit extensions")
                     IS_AARCH64 = False
@@ -288,12 +281,12 @@ def build_extension(self, ext: Extension):
             {
                 "sources": ["src/yencode/encoder_rvv.cc", "src/yencode/decoder_rvv.cc"],
                 "depends": srcdeps_enc_common + srcdeps_dec_common,
-                "gcc_rv_flags": gcc_rvv_flags,
+                "gcc_flags": gcc_rvv_flags,
             },
             {
                 "sources": ["src/yencode/crc_riscv.cc"],
                 "depends": srcdeps_crc_common,
-                "gcc_rv_flags": gcc_rvzbkc_flags,
+                "gcc_flags": gcc_rvzbkc_flags,
             },
             {
                 "sources": [
diff --git a/src/yencode/common.h b/src/yencode/common.h
index 90423eb..be66377 100644
--- a/src/yencode/common.h
+++ b/src/yencode/common.h
@@ -34,10 +34,6 @@
 	#define PLATFORM_ARM 1
 #endif
 
-#if defined(UNSUPPORTED_PLATFORM_ARM)
-#undef PLATFORM_ARM
-#endif
-
 #include <stdlib.h>
 #if defined(_MSC_VER) || defined(__MINGW32__) || defined(__MINGW64__)
 	// MSVC doesn't support C11 aligned_alloc: https://stackoverflow.com/a/62963007
diff --git a/src/yencode/crc_arm_pmull.cc b/src/yencode/crc_arm_pmull.cc
index a426d34..2691ccf 100644
--- a/src/yencode/crc_arm_pmull.cc
+++ b/src/yencode/crc_arm_pmull.cc
@@ -207,7 +207,7 @@ static uint32_t crc32_shift_pmull(uint32_t crc1, uint32_t n) {
 void RapidYenc::crc_pmull_set_funcs() {
 	_crc32_multiply = &crc32_multiply_pmull;
 	_crc32_shift = &crc32_shift_pmull;
-	_crc32_isa &= ISA_FEATURE_PMULL;
+	_crc32_isa |= ISA_FEATURE_PMULL;
 }
 
 #else


Test patch:
diff --git a/tests/test_crc32.py b/tests/test_crc32.py
index 94864dd..f44a794 100644
--- a/tests/test_crc32.py
+++ b/tests/test_crc32.py
@@ -10,8 +10,6 @@
         (0, 4294967295, 0, 4294967295),
         (4294967295, 4294967295, 0, 0),
         (4, 16, 256, 2385497022),
-        (18446744073709551615, 0, 0, 4294967295),
-        (18446744073709551615, 18446744073709551615, 0, 0),
         (100, 200, 300, 1009376567),
         (0, 0, 18446744073709551615, 0),
         (4294967295, 4294967295, 18446744073709551615, 0),