When the user said he's using the same binary as yours, he might said that by mistake -- you need to compare sha1sums of the binaries to make sure -- he might be running different .exe than yours.
I considered that but it's more than one user. And I downloaded the same binaries they did, and they stated they used
the westmere build, filename cpuminer.exe. So it is a copy of the same file not a reproduction. Also that is the only
build that does not support AES+AVX. Had the users tried the wrong file it would crash. Some did and reported same.
I don't know precisely how it was compiled but assuming I'm not being similarly misinformed by several users
my observations seem correct. The same file shows a different result for __AES__ on different CPU architectures.
I don't know which is correct but they should be the same.
Here is a bit of direct output of the variables used in the logic compiled for corei7
********** cpuminer-opt 3.3.4 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
Forked from TPruvot's cpuminer-multi with credits
to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
Wolf0 and Jeff Garzik.
cpu has_aes 1
cpu has_avx 1
sw_has_aes 0
sw_has_sse2 1
Checking CPU capatibility...
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
CPU arch supports AES-AVX...YES.
SW built for AES-AVX........NO.
Algo supports AES-AVX.......YES.
Starting mining without AES-AVX optimizations...
I've removed the warning messages otherwise no change from 3.3.3.
The result of the logic is not relevent in this example because the CPU has AES but the software check
is what's important. In this case sw_has_aes taken directly from __AES__ is false. This seems reasonable
for a westmere build and it agrees with my results from testing the CMB binary on the same CPU.
So I think I've gone in a complete circle and back to the same point. The CMB westmere binary displays a
different result for the __AES__ macro on different CPUs. Three users have reported he same problem with
actual westmere class CPUs because, for them, __AES__ returned false.
I am confident in the data reported by the users.
I am less confident about the nature of the CMB build. I don't know if they built native on westmere HW or
crosscompiled using -march=corei7. I could only verify indirectly by crosscompiling myself.
But even ignoring how the bin was built __AES__ should still produce the same result on any HW.
