search

microsoft / Microsoft-MPI

Microsoft MPI
MIT License
246 stars 74 forks source link

mpif.h header uses non-conformant integer representation leading to error with gfortran #14

Closed letmaik closed 4 years ago

letmaik commented 5 years ago

(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:

C:\Program Files (x86)\Microsoft SDKs\MPI\Include/mpif.h:399:32:

        PARAMETER (MPI_FLOAT_INT=z'8c000000')
                                1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1).
This check can be disabled with the option '-fno-range-check'

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?

letmaik commented 5 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

letmaik commented 5 years ago

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?

letmaik commented 5 years ago

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

AnnaDaly commented 4 years ago

should be fixed by #25