Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
letmaik opened this issue May 21, 2019 · 4 comments

Comments

@letmaik
Copy link
Member

letmaik commented May 21, 2019

(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
Copy link
Member Author

letmaik commented May 21, 2019

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
Copy link
Member Author

letmaik commented May 21, 2019

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
Copy link
Member Author

letmaik commented May 21, 2019

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
Copy link
Contributor

should be fixed by #25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants