Closed nkysg closed 11 months ago
This is a compiler bug, because gcc 9.4.0 compiles it correctly:
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # ls -la
total 44
drwxr-xr-x 2 root root 4096 Oct 27 13:56 .
drwx------ 8 root root 4096 Oct 27 13:55 ..
-rw-r--r-- 1 root root 25746 Aug 27 2021 jh.c
-rw-r--r-- 1 root root 849 Aug 27 2021 jh.h
-rw-r--r-- 1 root root 1489 Oct 27 13:55 main.c
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # gcc -O3 *.c -o test
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # ./test
0xea252e4fe0d223d17925f61058e2809da4896f12db26fce35faa5534575b8ce0
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # gcc -Ofast *.c -o test
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # ./test
0xea252e4fe0d223d17925f61058e2809da4896f12db26fce35faa5534575b8ce0
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # gcc --version
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Copyright (C) 2019 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.
Incorrect result for gcc 11.4.0 confirmed:
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # gcc-11 -O3 *.c -o test
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # ./test
0x48e84a3a785b8d5038d46c46ad4a09e2b8e019a6a8450acec7f36851c8dab0a7
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # gcc-11 --version
gcc-11 (Ubuntu 11.4.0-2ubuntu1~20.04) 11.4.0
Copyright (C) 2021 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.
If I compile with UB sanitizer, the error magically disappears, and no undefined behavior is found:
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # gcc-11 -O3 *.c -o test -fsanitize=undefined
root@Ubuntu-2004-focal-64-minimal-hwe ~/jh # ./test
0xea252e4fe0d223d17925f61058e2809da4896f12db26fce35faa5534575b8ce0
So it's a compiler bug.
Ok, I found the old fix I did for XMRig: https://github.com/xmrig/xmrig/commit/75c57f7563b974060088a868bdde1f70fc6dcf82
This is now in #9042 and #9043
@SChernykh Thanks for your fix.
I have seen https://www3.ntu.edu.sg/home/wuhj/research/jh/jh_sse2_opt64.h is optimize for sse2 and it 3 times faster. Do you have a plan to support it ? @SChernykh thanks!
There is no point to optimize this part of the code. Even when Cryptonight was Monero's PoW, this function accounted for < 0.1% of the hashing time, at best. Right now Cryptonight is only used as a key derivation function (KDF) for wallet files.
I find that there is a bug in cn_slow_hash. When I compiled code use gcc 11.4 on ubuntu22. The compiler flag O2 and O3 get different results. The reason is caused by jh_hash. This is the code in main.c
the Makefile is this https://github.com/nkysg/jh-function-issue/blob/monero/src/Makefile
run ./main2 it print 0xea252e4fe0d223d17925f61058e2809da4896f12db26fce35faa5534575b8ce0 run ./main3 it print 0x48e84a3a785b8d5038d46c46ad4a09e2b8e019a6a8450acec7f36851c8dab0a7
the fact is that monero jh.c is same code as https://www3.ntu.edu.sg/home/wuhj/research/jh/jh_ansi_opt64.h. I have tested the https://www3.ntu.edu.sg/home/wuhj/research/jh/jh_sse2_opt64.h compile use O2 and O3 the result is same. The test code is in this https://github.com/nkysg/jh-function-issue/tree/monero. If anyone has a plan to fix this bug. Thanks.