GitLab

A random matrix is set up, and then result = a**T * 2*b is computed
this is compared with the result of plain scalapack routines and
the maximum norm of "scalapack - elpa" is computed (should be zero on
machine precision)

The actual reason for the linker problems was that the Fortran libraries
where listed before the object files, by modifying the _LINK automake
variables. The proper way to do is of course to add the necessary
libraries after the object files by appending them to the _LDADD
variables.

As the MPI module was not responsible for the linker problems it is now
used by default, unless explicitly switched off with

  --disable-mpi-module

Also, the C test programs that had these linker errors where previously
not compiled in the OpenMP case, for no obvious reason. Now they are
also included there.

These functions were made private with ELPA releases 2016.05.001
and 2016.05.002, but they should be public

Now they just cluttered the main build directory, put them also in
private_modules/. This of course assumes that no two test programs
define modules with the same name.

Also, this necessitates that the shared sources are also only compiled
once, thus I put them into an internal libtool convenience library and
link all test programs with it.

Remove all references to private functions and symbols from the public
Fortran modules. Install also only the public modules

If compiled with MPI, the necessary "mpiexec -n 2" was not written
in the check scripts. This commit is based on a patch provided by
Michael Banck from debian.org

The QR decomposition test program can now called with parameters for
matrix size, nev, and block size.
This closses issue #20

Michael Bankd (debian) provided a patch, which allows
to run the qr-decomposition test programs with smaller matrices, and
thus allows testing in reasonable time on limited hardware (e.g. arm
devices)

In order to make the patch work, also Makefile.am was updated

Now this is done consistently both in autoconf and automake. One can now
safely call make clean and the header files are re-generated
automatically.

Automake does not easily allow to use the same source in a libtool
library and in a program

The issue why these test programs are simply not build
has to be investigated

It turned out that if a CPU supports SSE the already existing
test for SSE assembly instructions always passes.
However, the compilation of gcc SSE intrinic instructions might
nevertheless fail if gcc is not called with one of the options
"-msse3", "-msse4" , "-msse4.1", "-msse4.2", "-mavx", or "-mavx2"!

Obviously gcc does still not consider SSE as a standard on X86_64
Intel CPUs.

An additional configure test has been introduced, which test for
gcc intrinsic sse instructions. If this test fails, the corresponding
kernels are switched off.

The C++ kernels can be written as C kernels, which simplifies the build
procedure