Skip to content

fortran bindings: use assumed rank syntax if supported #10266

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

Closed

Conversation

hppritcha
Copy link
Member

If the fortran compiler being used to build the fortran bindings
supports it, use assumed rank rather than assumed size argument types.

This brings Open MPI into compliance with the MPI standard wrt the fortran bindings.

Signed-off-by: Howard Pritchard [email protected]

If the fortran compiler being used to build the fortran bindings
supports it, use assumed rank rather than assumed size argument types.

This brings Open MPI into compliance with the MPI standard wrt the fortran bindings.

Signed-off-by: Howard Pritchard <[email protected]>
@hppritcha hppritcha marked this pull request as draft April 12, 2022 17:58
@hppritcha
Copy link
Member Author

@awlauria here you go!

@hppritcha
Copy link
Member Author

@ibm-ompi
Copy link

The IBM CI (XL) build failed! Please review the log, linked below.

Gist: https://gist.github.com/e31c4f6939ff21b4bf15dd5ae5ff4834

@ibm-ompi
Copy link

The IBM CI (GNU/Scale) build failed! Please review the log, linked below.

Gist: https://gist.github.com/4faae646df484b43dec73acfd88cd2b1

@hppritcha
Copy link
Member Author

Okay some digging into passing assumed rank objects (which is what the MPI standard mandates for f08) to 'c' routines is non-trivial.

See https://www.ibm.com/docs/en/xl-fortran-aix/15.1.2?topic=procedures-assumed-rank-objects-ts-29113.

The 'c' function doesn't get a pointer to the actual argument being passed in in this case, but rather a pointer to a CFI_cdesc_t struct defined in the iso_fortran_binding.h header file that comes with the compiler suite being used.

Here's the 'c' function that MPICH invokes from the f08 version of MPI_Send:

int MPIR_Send_cdesc(CFI_cdesc_t *buf, int count, MPI_Datatype datatype,
                    int dest, int tag, MPI_Comm comm)
{
    int err = MPI_SUCCESS;
    void *buf_i = buf->base_addr;
    int count_i = count;
    MPI_Datatype datatype_i = datatype;

    if (buf_i == &MPIR_F08_MPI_BOTTOM) {
        buf_i = MPI_BOTTOM;
    }

    if (buf->rank != 0 && !CFI_is_contiguous(buf)) {
        err = cdesc_create_datatype(buf, count, datatype, &datatype_i);
        count_i = 1;
    }

    err = MPI_Send(buf_i, count_i, datatype_i, dest, tag, comm);

    if (datatype_i != datatype) PMPI_Type_free(&datatype_i);
    return err;
}

MPICH's f08 module file is correct according to the standard. The MPI_Send interface is defined as:

    INTERFACE MPI_Send
        SUBROUTINE MPI_Send_f08ts(buf, count, datatype, dest, tag, comm, ierror)
            USE :: mpi_f08_types, ONLY : MPI_Datatype, MPI_Comm
            IMPLICIT NONE
            TYPE(*), DIMENSION(..), INTENT(in) :: buf
            INTEGER, INTENT(in) :: count
            TYPE(MPI_Datatype), INTENT(in) :: datatype
            INTEGER, INTENT(in) :: dest
            INTEGER, INTENT(in) :: tag
            TYPE(MPI_Comm), INTENT(in) :: comm
            INTEGER, OPTIONAL, INTENT(out) :: ierror
        END SUBROUTINE MPI_Send_f08ts

        SUBROUTINE MPI_Send_f08ts_large(buf, count, datatype, dest, tag, comm, ierror)
            USE :: mpi_f08_types, ONLY : MPI_Datatype, MPI_Comm
            USE :: mpi_f08_compile_constants, ONLY : MPI_COUNT_KIND
            IMPLICIT NONE
            TYPE(*), DIMENSION(..), INTENT(in) :: buf
            INTEGER(KIND=MPI_COUNT_KIND), INTENT(in) :: count
            TYPE(MPI_Datatype), INTENT(in) :: datatype
            INTEGER, INTENT(in) :: dest
            INTEGER, INTENT(in) :: tag
            TYPE(MPI_Comm), INTENT(in) :: comm
            INTEGER, OPTIONAL, INTENT(out) :: ierror
        END SUBROUTINE MPI_Send_f08ts_large
    END INTERFACE MPI_Send

@bosilca
Copy link
Member

bosilca commented Apr 13, 2022

@ggouaillardet did some work in this direction a few years ago, but it received little interest from the OMPI community. Check #6569 for more details.

@hppritcha
Copy link
Member Author

thanks @bosilca I'll at least rebase #6569 and see what passes with CI now.

@hppritcha
Copy link
Member Author

this is a dup of #6569 so closing this PR.

@hppritcha hppritcha closed this Apr 13, 2022
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

Successfully merging this pull request may close these issues.

3 participants