(Z13 ) Blas1 mikrokernels can be inlined by gcc. Refactoring,fixes,tunings

names). Some fixes and tunings

(Z systems Z13) small fixes, some (i(dz)amin,i(dz)amax,(dz)dot,(dz)asum) mikrokernels…

Address warnings #1357

Make: escape paths to pkg-config file

Add double quotes around the path to the pkg-config file so that a path
containing whitespace does not break the build.

Tag %1 and %2 as both input and output operands

fix from #1292 extended to the other gemv microkernels

Appveyor: speed up fortran builds

Tag %1 and %2 as both input and output

Address few more warnings

The inline assembly modifies its input operands, so mark them as output to avoid surprises with optimization. Fixes #1292

Fix LAPACKE build problems with both cmake and make

The macOS ar aborts when it gets called with no input, see #1398

These were inadvertently dropped from the list in my PR #1095

Retire Piledriver/Steamroller/Excavator daxpy microkernels as well

related to issue #1332

Use Sandybridge daxpy kernel on Haswell and Zen for now

The testcase from #1332 exposes a problem in daxpy_microk_haswell-2.c that is not seen with
any of the other Intel x86_64 microkernels.

* Calculation of chunk range limits was ignoring num_cpu

bug introduced by me in #1262 - should fix #1388

* Calculation of range limits was ignoring num_cpu

bug introduced by me in #1262

* Calculation of chunk range limits was ignoring num_cpu

bug introduced by me in #1262

* Calculation of chunk range limits was ignoring num_cpu

bug introduced by me in #1262

* Calculation of chunk range limits was ignoring num_cpu

bug introduced by me in #1262

* Calculation of chunk range limits was ignoring num_cpu

bug introduced by me in #1262

* dead increments in driver/level2

* dead increments in kernel/generic

* part dead increments in kernel/x86_64

Work around errors in multithreaded dtrmv

Limit MAX_CPU to 1024 for now

Explicitly link against libm on Android with cmake as well

Patch from #1384

Some Linux distributions (notably SuSE) have raised CPU_SETSIZE to 4096, apparently disregarding API limitations.
From #1348, the highest value to survive array initialization (on a desktop system) is 3232, and 1024 - which is the 
more usual CPU_SETSIZE limit, was demonstrated to work fine on an actual bignuma system.

as a (hopefully temporary) workaround for #1332

as a (hopefully temporary) workaround for #1332

Fix compiler warnings in ctest

Various fixes for const correctness, stray tab characters and unused labels

Work around compiler warnings for unused variables

Correct zgeadd_k prototype

* Prefix make with travis_wait to prevent it getting killed for producing no output

* Extend travis_wait to 30mins for the windows build

* Trying 45 mins wait time

* Increase travis_wait time to 45 minutes for linux builds as well

Allow overriding NUM_THREADS in cmake

[appveyor] fix test directory

[appveyor] Use out-of-tree build and cache