GitLab

This prevented compilation with Intel 2018 Beta and solves issue #54. It
turns out you can only override type-bound procedures that are
accessible in the module where you override them, thus they have to be
private. A "deferred, private" type bound procedure could only be
overriden from the same module (or a submodule thereof).

Many thanks to Igor Vorobtsov from Intel for clarifying this.

Pavel noted that some header files were missing from the distribution.
Also, I moved the private generated header files to src/ in order to
more clearly separate them.

Introducing python script plot.py containing several classes used to
plot matrices stored in block-cyclic distribution as a 1 global matrix.
Docstrings in plot.py should explain the ussage. There are also two
use cases included, both with commented scripts (using classes from
plot.py) and a screenshot. One of the use cases contains also tarball
with data.

Apart from that, a VERY simple module matrix_plot.F90 was created. It
is really simplistic, a more systematic approach towards loging should
be designed. At the moment, matrix output has to be triggered explicitly
in the code by calling a macro SAVE_MATR(event_description, iteration).

PGI compiler does not like too long lines even though they are comments

The PGI compiler (of course) complained about a missing module
(elpa_generated_fortran_interfaces.mod) when compiling the test
programs.

It is true (in a way) that some part of this module is indeed necessary,
as the public-facing function signatures have arguments that are
referring to those three functions in their type:

  elpa_strerr_c(elpa_error)
  elpa_int_value_to_string_c(name, value, string)
  elpa_int_value_to_strlen_c(name, value)

Thus, for these three we create another header prefix,

  !pf>

for Fortran definitions that should be public. Those are included in
elpa_api.F90.

It is not quite clear to me why GCC complains here when
WANT_SINGLE_PRECISION_REAL is not defined, as the variables are then not
used _at all_.

Nonetheless, this again prevents build on the SuSE OBS, so fix it to
make the compiler happy

Recent GCC complain that an assignment involving a transfer statement
might potentially overflow the destination buffer. This prevented a
build on the SuSE build server.

Replaced this with a proper C string pointer.

Error message there:

 ../src/elpa_driver/legacy_interface/./elpa_driver_c_interface_template.X90:117:0:

        methodFortran(1:charCount) = transfer(method(1:charCount), methodFortran)

 Warning: '__builtin_memset': writing between 1 and 2147483640 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

 [...]

 I: Statement might potentially overflow a destination buffer, where a size larger
     than the actual buffer was specified
 E: elpa destbufferoverflow Warning: '__builtin_memset'

There was an error in the strip_width calculation leading to wrong
results for certain values of 'nev'. This is still not properly
investigated, should be checked again.

Exchange _mm512_load_pd()/_mm512_load_ps() of stack variables with
_mm512_set_pd, as the stack variables might not have proper alignment!