Closed letmaik closed 4 years ago
Comment by @jithinjosepkl:
Maik,
We looked into this, but it needs the underlying datatype format to be modified. We are also evaluating adoption of CH4, which does not have this issue.
Will update this thread if we come up with another solution.
-Jithin
Comment by @letmaik:
I don't understand why the datatype would have to be changed. If you change it to
PARAMETER (MPI_FLOAT_INT=-1946157056)
then that fits into INTEGER(4) which is the underlying datatype, right?
Comment by @jithinjosepkl:
Hi Maik,
Sorry, missed to update you on this. Yep, you are right, with -1946157056, it should not result in overflow. Btw, I initially thought of changing the MPI datatype representation format (as the later versions of MPICH did), and not the MPI_FLOAT_INT datatype (INTEGER(4)). We can get this in for the next release .
Please feel free to use github for future issue reports/comments.
Thanks, Jithin
should be fixed by #25
(Originally posted on Windows HPC MPI Forum)
Very old versions of mpich (1.x) used the z'8c000000' notation to represent integers. This has since been changed so that regular decimal numbers are used, in this case -1946157056. MS MPI still uses the old way.
Compiling an application with gfortran and the MS MPI mpif.h header leads to this error:
The issue here is that z'8c000000' initially represents 2348810242 which is bigger than 32bit (=Integer) and wouldn't fit. By adding the -fno-range-check option this value overflows into the negative space and ends up at the right number. However, this is a very bad approach, since it means that you have to enable this flag for all source files that include the mpif.h header and essentially remove valuable error messages.
Can MS MPI be updated to not use this non-conformant behaviour so that applications built with gfortran and MS MPI don't have to use the mentioned flag?