The OSX assembler apparently mishandles the argument to decimal .align, leading to a significant loss of performance 
as observed in #730, #901 and most recently #1470

* Restore the remaining utests

* Try fork test on Cygwin and Linux only, it hangs on at least ARMv8/Android as well

* Use generic sswap/dswap kernels for NEHALEM 32bit to fix fault found by the restored swap utest

* Disable zdotu test for MS cl to work around runtime error -1073741819 on AppVeyor for now
(probably coding error in the initialization of the complex numbers or wrong choice of zdotu API)

ref #1439

small corrections

Initialize unitialized values for repeated calls

small fix inside ifdef z13mvc . (z13mvc code is not used in production)

Fixes #1432 (and possibly other DTRMM-related failures on Haswell and related architectures when built with cmake)

(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

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

fix from #1292 extended to the other gemv microkernels

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

related to issue #1332

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.

* dead increments in driver/level2

* dead increments in kernel/generic

* part dead increments in kernel/x86_64

Add trivially optimized DSDOT for POWER8

Add optimized dsdot to all other x86_64 kernels that use sdot.c

Clean up spurious unused variables in the kernels