OpenMPI configure script wrongly recognizes which directive to use for ignoring tkr in case of the new LLVM Fortran compiler

[pawosm-arm]

OpenMPI configure script wrongly recognizes which directive to use for ignoring tkr in case of the new LLVM Fortran compiler

[pawosm-arm]

It works great,

checking Fortran compiler ignore TKR syntax... not cached; checking variants
checking for Fortran compiler support of TYPE(*), DIMENSION(*)... no
checking for Fortran compiler support of !GCC$ ATTRIBUTES NO_ARG_CHECK... no
checking for Fortran compiler support of !DIR$ IGNORE_TKR... yes
checking Fortran compiler ignore TKR syntax... 1:type(*):!DIR$ IGNORE_TKR
checking if Fortran compiler supports ISO_C_BINDING... yes
checking if building Fortran 'use mpi' bindings... yes

In the generated mpi-f08-interfaces.h file:

interface  MPI_Recv_init
subroutine MPI_Recv_init_f08(buf,count,datatype,source,tag,comm,request,ierror)
   use :: mpi_f08_types, only : MPI_Datatype, MPI_Comm, MPI_Request
   implicit none
   !DIR$ IGNORE_TKR buf
   type(*) OMPI_ASYNCHRONOUS :: buf
   INTEGER, INTENT(IN) :: count, source, tag
   TYPE(MPI_Datatype), INTENT(IN) :: datatype
   TYPE(MPI_Comm), INTENT(IN) :: comm
   TYPE(MPI_Request), INTENT(OUT) :: request
   INTEGER, OPTIONAL, INTENT(OUT) :: ierror
end subroutine MPI_Recv_init_f08
end interface  MPI_Recv_init

It took me a while, but I'd also needed to verify it works with spack and finally, I've managed to build all the workload I needed! Thanks for quick solving this problem! :)

[jsquyres]

FYI: This fix will be included in the next v5.0.x release.

[pawosm-arm]

Note that the CMake scripts may be affected similar way.

The top-level OpenMPI project doesn't use CMake.

[ggouaillardet]

Thanks for the report!

I am able to reproduce it and will have a look.

FWIW, with LLVM 18.1.4, I first faced an issue with ASYNCHRONOUS (accepted in interfaces but not subroutines (!))
the inline patch below helped me

Can you please confirm which LLVM version you are running and your Open MPI configure command line?

diff --git a/config/ompi_fortran_check_asynchronous.m4 b/config/ompi_fortran_check_asynchronous.m4
index 0cc3c84bfe..061511730b 100644
--- a/config/ompi_fortran_check_asynchronous.m4
+++ b/config/ompi_fortran_check_asynchronous.m4
@@ -35,6 +35,10 @@ SUBROUTINE binky(buf)
  REAL, DIMENSION(*), ASYNCHRONOUS :: buf
 END SUBROUTINE
 END INTERFACE
+CONTAINS
+SUBROUTINE wookie(buf)
+ REAL, DIMENSION(*), ASYNCHRONOUS :: buf
+END SUBROUTINE
 END MODULE asynch_mod]])],
              [AS_VAR_SET(asynchronous_var, yes)],
              [AS_VAR_SET(asynchronous_var, no)])

[pawosm-arm]

Thanks for your prompt response!

For my experiments, I'm using fairly recent LLVM built from the main branch:

$ mpifort --version
flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 3197146cc6ae1cefe0b21326f0509add3369decb)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir:
Build config: +unoptimized, +assertions

I guess the feature you've mentioned has been implemented by this commit:

commit f31ac3cb1ff7958fadf6e3e431790f2d668583b4
Author: Peter Klausler <[email protected]>
Date:   Fri Mar 1 14:43:31 2024 -0800

    [flang] Handle implied ASYNCHRONOUS attribute (#82638)

    The standard states that data objects involved in an asynchronous data
    transfer statement gain the ASYNCHRONOUS attribute implicitly in the
    surrounding subprogram or BLOCK scope. This attribute affects the checks
    in call semantics, as an ASYNCHRONOUS actual object associated with an
    ASYNCHRONOUS dummy argument must not require data copies in or out.

    (Most compilers don't implement implied ASYNCHRONOUS attributes
    correctly; XLF gets these right, and GNU is close.)

I've verified that the git log starting from the llvmorg-18.1.4 does NOT contain this commit.

[ggouaillardet]

thanks, that makes more sense to me now!

I will rebuild LLVM and try again.

[pawosm-arm]

I think I was too fast with my response. This commit refers to implied attribute, while your code explicitly name it.
If you still encounter the problem, can you paste the error message? I haven't seen it myself yet.

[ggouaillardet]

I issued #12512 to address the false positives and enable IGNORE_TKR with upcoming LLVM 19.

Can you please give it a try?

[janjust]

fixed with: #12512