RFv2 hash mismatch with -O3 flag

[itwysgsl]

I've tested RFv2 on testnet recently and noticed that cpuminer builded with -O3 flag as @wtarreau proposed here #15 produce invalid hashes. After I recompiled cpuminer without -O3 flag, I finally managed to mine first RFv2 block.

[wtarreau]

This is interesting. It could be a compiler bug or a border-line optimization such as some aliasing (I noticed the code has quite a bit of it). What compiler version is this ? Also could you dump the options enabled at both levels this way:

gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep ^+

It's interesting because I tried to run the code on the intel GPU in my CPU but it takes a while to start and reports an invalid hash. It could be related to the same issue.

The performance is still very low compared to rf_test. I have not tested the cpuminer patch recently, I suspect it spends time initializing the rambox.

[itwysgsl]

@wtarreau here is what I got, probably clang have some platform specific differences 🤔

gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
clang: error: unsupported option '--help=optimizers'
clang: error: no input files

gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
clang: error: unsupported option '--help=optimizers'
clang: error: no input files

[wtarreau]

Ah that's sad. What clang version is this ?

Oh on my machine with clang 3.8 it fails "rfv2_test -c" with any optimization option other than -O0. That's getting interesting ;-)

[itwysgsl]

Here is my clang specs:

clang -v
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[itwysgsl]

Btw, not sure if I mentioned it before, but I also had very odd issue with original rainforest builded as python module on macOS. It's described here.

[wtarreau]

OK I found the issue, it was caused by an incorrect rotation operation : depending on how the compiler optimizes it, it either works or not. It's one of these annoying issues when trying to implement rotations in C, you're torn between undefined behaviour the compiler can correctly map to the rol/ror instruction or slow implementation... I went for the valid implementation and added the asm equivalent for x86_64. I may do the same for armv8 later. This is in pr#18.

[itwysgsl]

Thanks @wtarreau. PR #18 fixed this issue, and now everything works just fine :)

[wtarreau]

On Sun, Apr 07, 2019 at 10:18:40PM -0700, iamstenman wrote: Thanks @wtarreau. PR #18 fixed this issue, and now everything works just fine :)

Ah cool, thanks for reporting! This issue comforted me in the usefulness of a project I started long ago to provide reliable and portable low-level functions! Willy