mpif.h header uses non-conformant integer representation leading to error with gfortran RRS feed

  • General discussion

  • 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?

    Tuesday, August 7, 2018 7:20 AM

All replies

  • Thanks Maik for reporting this, we will take a look at this.
    Tuesday, August 7, 2018 9:25 PM
  • 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.


    Friday, November 9, 2018 7:17 PM
  • 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?

    Saturday, November 10, 2018 11:09 AM
  • Ping. Do you want to move the discussion to GitHub or will this forum stay as contact point?
    Tuesday, December 18, 2018 10:09 PM
  • 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.


    Wednesday, December 19, 2018 6:50 AM
  • Tuesday, May 21, 2019 9:52 PM