[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[pallas]

performance report with 3.0.2:

        AMD FX(tm)-8320 Eight-Core Processor           
AES_NI: Yes, start mining with AES_NI optimizations...

[2016-01-22 12:01:02] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-22 12:01:02] 8 miner threads started, using 'x11' algorithm.
[2016-01-22 12:01:02] Stratum difficulty set to 0.016
[2016-01-22 12:04:22] accepted: 1/1 (100.00%), 364.68 kH/s yes!
[2016-01-22 12:06:12] accepted: 2/2 (100.00%), 353.90 kH/s yes!
[2016-01-22 12:08:01] accepted: 3/3 (100.00%), 344.48 kH/s yes!
[2016-01-22 12:10:11] accepted: 4/4 (100.00%), 340.22 kH/s yes!
[2016-01-22 12:10:44] accepted: 5/5 (100.00%), 340.28 kH/s yes!

[1715285826]

1715285826

[1715285826]

1715285826

[1715285826]

1715285826

[pallas]

Tried compiling on a non-aesni cpu (core2), but it tries to use  aesni on cryptonight:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^

I posted about this back half a page or so. Try using -march=corei7-avx. It seems counter intuitive but we need
to fool the compiler to compile the AESNI code. Once compile the run time checks will avoid falling into it.
If you know of the appropriate compiler directive to check CPU architecture, please advise.

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

[joblo]

Tried compiling on a non-aesni cpu (core2), but it tries to use  aesni on cryptonight:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^

I posted about this back half a page or so. Try using -march=corei7-avx. It seems counter intuitive but we need
to fool the compiler to compile the AESNI code. Once compile the run time checks will avoid falling into it.
If you know of the appropriate compiler directive to check CPU architecture, please advise.

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

If you're confirming it works for you, I'll document in the build instructions for next release. Know
how to do it on VS?

[pallas]

Tried compiling on a non-aesni cpu (core2), but it tries to use  aesni on cryptonight:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^

I posted about this back half a page or so. Try using -march=corei7-avx. It seems counter intuitive but we need
to fool the compiler to compile the AESNI code. Once compile the run time checks will avoid falling into it.
If you know of the appropriate compiler directive to check CPU architecture, please advise.

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

If you're confirming it works for you, I'll document in the build instructions for next release. Know
how to do it on VS?

I don't know if it works, it must be implemented first :-)
On linux you need to modify the m4 files and, possibly, add some precompiler directives.
That's why I suggested looking at how Wolf0 did it on his miner.

[bobben2]

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0

Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with
AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue.
the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions
the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks
the CPU architectire in order to select code to run for the correct CPU architecture.

I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact
we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it
compiles. If successful try to run it and note the startup messages regarding the CPU capabilities.

I hope this works.

Edit: Only 64 bit CPU are supported.

I changed march as you suggested.  I got a bit further, but still errors.
I commented out the content of the functions in  algo/sse2/groestl/grso-asm.c as it was throwing errors.
Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing:

Code:

#include <stdio.h>

void quarkhash_aes()  { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() {  fprintf(stderr,"Nor this\n"); }

I then got the program linked, but it core dumps when I start it:
 
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm.
/home/arve/miner_cpu_qubit: line 11:  3379 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion..

Here is the info from gdb after I recompiled with -g

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8,
    out=0x7f69bae93a88) at strconv.c:69
69          value = strtod(strbuffer->value, &end);
(gdb)

[joblo]

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0

Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with
AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue.
the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions
the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks
the CPU architectire in order to select code to run for the correct CPU architecture.

I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact
we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it
compiles. If successful try to run it and note the startup messages regarding the CPU capabilities.

I hope this works.

Edit: Only 64 bit CPU are supported.

I changed march as you suggested.  I got a bit further, but still errors.
I commented out the content of the functions in  algo/sse2/groestl/grso-asm.c as it was throwing errors.
Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing:

Code:

#include <stdio.h>

void quarkhash_aes()  { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() {  fprintf(stderr,"Nor this\n"); }

I then got the program linked, but it core dumps when I start it:
 
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm.
/home/arve/miner_cpu_qubit: line 11:  3379 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion..

Here is the info from gdb after I recompiled with -g

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8,
    out=0x7f69bae93a88) at strconv.c:69
69          value = strtod(strbuffer->value, &end);
(gdb)

Thanks a lot for the data. It's clear  the support for older cpus just isn't there yet. That's what happens when one can't
ddo his own testing I need to change that. I have a core2quad but it runs windows, I guess I'll have to get widows
workinh sooner than later..

In the meantime, since youseem comfortable in the code I have a request to gather more data with some instrumented
code.

In file cpu-miner.c, function miner_thread there is a big switch statement casing on each algo. You will notice how
I select the proper kernel. Simly comment out a few lines to force either the sse2 version or x64 version to run
regardless of the detected CPU technology.

If you could do this for several algos it would help identify any code contamination.

The sausage factory in action. It ain't pretty and better done behind closed doors.

Edit: try forcing all three kernels to run to see at what level your core2 fails. thanks

[bobben2]

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

[joblo]

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

It looks like I have a lot of work to do. And getting windows to work has become a higher priority so I
can do my own testing on a core2.

I'll finish up v3.0.3 then get to work on windows.

[joblo]

A compile issue has been discovered whenusing older CPUs that don't support AES_NI,
specifically a core2.

I am reconsidering support for older HW in light of the fact there seems to be little
demand for it.

The cpuminer-opt package includes AES_NI code that can't run  on the native CPU. The
configure command includes the compile option "-march=native" tells the compiler not to
compile code that can't run on the native CPU. As a result the compiler throws an error and
the compile fails.

The code has runtime checks to isolate the AES_NI code from incompatible CPUs, the issue
is compiling.

I have suggested a workaround to change the compile option to specify an architecture that
does support AES_NI. To do this change "-march=native" to "-march=corei7-avs" or someting
similar.

At his time I have no feedback on the success of this workaround.
Should the workaround fail I will be forced with a decision.

I can try to find a compiler directive to selectively exclude specific code based on architecture.
I that is unsussesful I will have a couple of options.

I could drop support altogether for non AES_NI CPUs. The is still the TPruvot fork that is compatible
with all x86_64 CPU. But that leaves out the in-betweeners that have sse2 but not AES_NI.

I'm almost finished with the sse2 optimizations so I could build a special final release for sse2.
but only if there is interest. And I don't mean posting and saying do it. I mean substantial interest
like posting results showing you are trying to use cpuminer-opt. on an old CPU.
Please note that x86_64 is the absolute minimum HW arctitecture supported.

How 'bout it?  

Edit: I have some small hashrate increases in a couple of algos but not enough for another release yet.

This problem is bigger than I anticipated. Along with the compile issues it appears  the advanced code isn't
properly identified and isolated.

In order to gather more information I will provide two special packages targeted for x86_64 and SSE2 each. That
will allow users to directly control which kernel is run. Hopefuly later today.

[bobben2]

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0

Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with
AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue.
the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions
the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks
the CPU architectire in order to select code to run for the correct CPU architecture.

I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact
we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it
compiles. If successful try to run it and note the startup messages regarding the CPU capabilities.

I hope this works.

Edit: Only 64 bit CPU are supported.

I changed march as you suggested.  I got a bit further, but still errors.
I commented out the content of the functions in  algo/sse2/groestl/grso-asm.c as it was throwing errors.
Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing:

Code:

#include <stdio.h>

void quarkhash_aes()  { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() {  fprintf(stderr,"Nor this\n"); }

I then got the program linked, but it core dumps when I start it:
 
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm.
/home/arve/miner_cpu_qubit: line 11:  3379 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion..

Here is the info from gdb after I recompiled with -g

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8,
    out=0x7f69bae93a88) at strconv.c:69
69          value = strtod(strbuffer->value, &end);
(gdb)

Thanks a lot for the data. It's clear  the support for older cpus just isn't there yet. That's what happens when one can't
ddo his own testing I need to change that. I have a core2quad but it runs windows, I guess I'll have to get widows
workinh sooner than later..

In the meantime, since youseem comfortable in the code I have a request to gather more data with some instrumented
code.

In file cpu-miner.c, function miner_thread there is a big switch statement casing on each algo. You will notice how
I select the proper kernel. Simly comment out a few lines to force either the sse2 version or x64 version to run
regardless of the detected CPU technology.

If you could do this for several algos it would help identify any code contamination.

The sausage factory in action. It ain't pretty and better done behind closed doors.

Edit: try forcing all three kernels to run to see at what level your core2 fails. thanks

I deleted all the source files, after suspecting make clean doesnt clean out all the object files. 
Then I did a fresh untar of version 3.0.2.
This time, it compiled and linked cleanly.   But still core dump when running.
I tried changing the miner_thread to force a particular cpu architecture, as you suggested:
    bool cpu_aesni = has_aes_ni();
    bool cpu_sse2  = has_sse2();
cpu_aesni = false;
cpu_sse2 = false;
then
cpu_aesni = false;
cpu_sse2 = true;
then
cpu_aesni = true;
cpu_sse2 = true;
but none worked.
I then tried to recompile with the -g switch, but I got new errors....

./algo/sse2/groestl/grso-asm.c: In function ‘grsoP1024ASM’:
./algo/sse2/groestl/grso-asm.c:6:3: error: ‘asm’ operand has impossible constraints
   asm (
   ^

Too many problems with the miner on this CPU.. It might take some effort to fix this.  You may want to put this lower on your priority list.

[joblo]

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0

Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with
AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue.
the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions
the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks
the CPU architectire in order to select code to run for the correct CPU architecture.

I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact
we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it
compiles. If successful try to run it and note the startup messages regarding the CPU capabilities.

I hope this works.

Edit: Only 64 bit CPU are supported.

I changed march as you suggested.  I got a bit further, but still errors.
I commented out the content of the functions in  algo/sse2/groestl/grso-asm.c as it was throwing errors.
Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing:

Code:

#include <stdio.h>

void quarkhash_aes()  { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() {  fprintf(stderr,"Nor this\n"); }

I then got the program linked, but it core dumps when I start it:
 
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm.
/home/arve/miner_cpu_qubit: line 11:  3379 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion..

Here is the info from gdb after I recompiled with -g

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8,
    out=0x7f69bae93a88) at strconv.c:69
69          value = strtod(strbuffer->value, &end);
(gdb)

Thanks a lot for the data. It's clear  the support for older cpus just isn't there yet. That's what happens when one can't
ddo his own testing I need to change that. I have a core2quad but it runs windows, I guess I'll have to get widows
workinh sooner than later..

In the meantime, since youseem comfortable in the code I have a request to gather more data with some instrumented
code.

In file cpu-miner.c, function miner_thread there is a big switch statement casing on each algo. You will notice how
I select the proper kernel. Simly comment out a few lines to force either the sse2 version or x64 version to run
regardless of the detected CPU technology.

If you could do this for several algos it would help identify any code contamination.

The sausage factory in action. It ain't pretty and better done behind closed doors.

Edit: try forcing all three kernels to run to see at what level your core2 fails. thanks

I deleted all the source files, after suspecting make clean doesnt clean out all the object files. 
Then I did a fresh untar of version 3.0.2.
This time, it compiled and linked cleanly.   But still core dump when running.
I tried changing the miner_thread to force a particular cpu architecture, as you suggested:
    bool cpu_aesni = has_aes_ni();
    bool cpu_sse2  = has_sse2();
cpu_aesni = false;
cpu_sse2 = false;
then
cpu_aesni = false;
cpu_sse2 = true;
then
cpu_aesni = true;
cpu_sse2 = true;
but none worked.
I then tried to recompile with the -g switch, but I got new errors....

./algo/sse2/groestl/grso-asm.c: In function ‘grsoP1024ASM’:
./algo/sse2/groestl/grso-asm.c:6:3: error: ‘asm’ operand has impossible constraints
   asm (
   ^

Too many problems with the miner on this CPU.. It might take some effort to fix this.  You may want to put this lower on your priority list.

Thanks for the testing. This is the kind of testing I should be doing behind closed doors. I'm going to fire up
cygwin to see if I get get  a testing environment on al oder CPU of my own.

For now consider SSE2 ans x86_64 unsupported, will update OP.

[pallas]

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

Of course it doesn't work. You compiled for a cpu which isn't compatible with yours. The compiler used some instructions which your cpu doesn't understand.

[joblo]

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

Of course it doesn't work. You compiled for a cpu which isn't compatible with yours. The compiler used some instructions which your cpu doesn't understand.

I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong.
I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels
are poluted with higher level code, among many other things.

I'll see if cygwin can come to my rescue.

[pallas]

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

Of course it doesn't work. You compiled for a cpu which isn't compatible with yours. The compiler used some instructions which your cpu doesn't understand.

I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong.
I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels
are poluted with higher level code, among many other things.

I'll see if cygwin can come to my rescue.

Hmmmm the check itself could be made of incompatible instructions.... every part of the code could. It's not just AES_NI but many other extensions as well.
You just can't compile for a pentium and expect it to run on a 386!

[joblo]

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

Of course it doesn't work. You compiled for a cpu which isn't compatible with yours. The compiler used some instructions which your cpu doesn't understand.

I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong.
I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels
are poluted with higher level code, among many other things.

I'll see if cygwin can come to my rescue.

Hmmmm the check itself could be made of incompatible instructions.... every part of the code could. It's not just AES_NI but many other extensions as well.
You just can't compile for a pentium and expect it to run on a 386!

Good point. The aesni check on an old cpu might return garbage results.

[joblo]

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

[joblo]

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

[zTheWolfz]

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I want to thank you for all your hard work, without your work I'd still be stuck in the stone age. lol
I now can do the same hashrate on a laptop and one SR2 that I was getting with 3xSR2's and
one 32 core AMD rig and the bigger catch is I'm making more with much less power. Old scyptjane
miner was 1.38 hash 3xSR2 plus the AMD rig. I'm now seeing 1.5 hash on just a laptop & 1x SR2.  

I"m having a bit of a problem compiling on the AMD rig with errors. All same software but I may
need different library files on the AMD system? I had errors of missing files on the Intel systems
but those were easy found by what it posted the errors where about, but not so with the AMD system.
Of course the main OS that the VM sets on is Windows Server and could be playing apart with the errors.

Its been a really long day "up over 24h" now and I'm not at that rig so I will go into that more when I'm sure
to be able to give all the correct info. I'd like to make a donation to you for your hard work but that will
have to wait a bit only 0.2 BTC in my wallet at the moment, but once I get every thing swapped over that should change quickly.

[joblo]

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Didn't someone tell me mingw was easy?

After peeling the onion with missing dll's  I ended up draggin along about ten of them.
But now there's something i've never seen.

cpuminer starts up but crashes on a call to parse-arg.  The function and the calls are all
in cpu-miner.c, there's nothng special about it just a simple function call. BUT wew nevr get
there. I have a printf on the line before the call to parse arg and another just inside the opening
brace in parse_arg and only one gets hit before the crash. Itg's crashing on a simple function call.

I dpn't know how to get past this.

[pallas]

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Didn't someone tell me mingw was easy?

After peeling the onion with missing dll's  I ended up draggin along about ten of them.
But now there's something i've never seen.

cpuminer starts up but crashes on a call to parse-arg.  The function and the calls are all
in cpu-miner.c, there's nothng special about it just a simple function call. BUT wew nevr get
there. I have a printf on the line before the call to parse arg and another just inside the opening
brace in parse_arg and only one gets hit before the crash. Itg's crashing on a simple function call.

I dpn't know how to get past this.

I compiled sgminer on windows using mingw, it wasn't trivial but following the instructions I made it.
About your specific crash issue, is it code you wrote or modified, or was it there for long?
Maybe it's just some issue with memory allocation.