ILP64 support

[albandil]

Some scientific Fortran based programs make use of global integer promotion to 8 bytes ("ILP64 mode"), which then requires compatible Fortran integer interface in BLAS, LAPACK and ScaLAPACK. For instance, OpenBLAS provides the 8-byte interface when compiled with an appropriate configuration flag. Intel MKL is offered in both LP64 and ILP64 versions, too.

This voluminous pull request adds the possibility to compile ScaLAPACK with long integers. This is achieved by replacing most int declarations by a macro Int, which by default evaluates to int, but can be overridden by the user in a different way using a compile-time definition. Compiling ScaLAPACK in the ILP64 mode (in Unix-like systems) then requires the following:

• add the flag -DInt=long to the C compiler flags
• add the flag -fdefault-integer-8 (or analogous, compiler-specific) to the Fortran compiler flags
• use BLAS/LAPACK with 8-byte integer interface (e.g. OpenBLAS compiled with INTERFACE64=1)

When the above is not done, the build process will work exactly as is did before, resulting in a LP64 library.

Furthermore, the MPI C interface is newly assumed to expect the type MpiInt, which is a macro again, by default evaluates to int, but can be (in hypothetical and very unlikely circumstances) overridden by the user as well. However, I know of no MPI C library providing other than LP64 interface, so this freedom will be most likely never used.

The test suite, as it is, contains hardcoded sizes of integers (4 bytes). Because ScaLAPACK is a Fortran 77 library, I have not taken the liberty to replace the fixed sizes by calls to the Fortran 95 function bit_size(), or the Fortran 2008 function storage_size(). Instead, to compile and run the test suite in the ILP64 mode, one needs to replace those hardcoded numbers manually (as stated in the README):

    sed -i 's/INTSZ = 4/INTSZ = 8/g'   TESTING/EIG/* TESTING/LIN/*
    sed -i 's/INTGSZ = 4/INTGSZ = 8/g' TESTING/EIG/* TESTING/LIN/*

All tests then succeed except for "xssep", "xsgsep" and "xssyevr", whose workspace handling is unfortunately written with the assumption that the byte size of an integer does not exceed the byte size of a (default, single precision) real, which is not true in case of the ILP64 configuration.

Apart from the ScaLAPACK test suite, I have been using this branch for two years now for large-scale pdsyevd runs without any issues. Other functionality is not so well tested.

[julielangou]

Thank you so much for this much needed contribution.

[jeffhammond]

Furthermore, the MPI C interface is newly assumed to expect the type MpiInt, which is a macro again, by default evaluates to int, but can be (in hypothetical and very unlikely circumstances) overridden by the user as well. However, I know of no MPI C library providing other than LP64 interface, so this freedom will be most likely never used.

Sorry, but this is just wrong. The MPI standard uses int and no other type is conforming. There is no scenario involving a valid implementation of MPI where MpiInt should ever be used.

The MPI standard has MPI_Fint specifically to ensure compatibility with the MPI Fortran library, and only this type should be used for this purpose.

I don't have strong feelings about Int but MpiInt should be removed. Its existence is dangerous and unnecessary.

[albandil]

@jeffhammond Thanks for raising this issue! My knowledge of MPI implementations improved a lot since I wrote this code years ago and I agree now that there is no real use case for MpiInt. Then it is indeed best to remove it.