Thanks Paul! I do not doubt that our configury has some not-quite-perfect Fortran tests; I know enough Fortran to be dangerous -- I am definitely not a Fortran expert.
Themos from NAG has been iterating with us on https://github.com/open-mpi/ompi/pull/9812 -- we're closer, but we haven't fixed everything yet. -- Jeff Squyres jsquy...@cisco.com ________________________________ From: users on behalf of Paul Kapinos via users Sent: Tuesday, January 4, 2022 4:27 AM To: Jeff Squyres (jsquyres) via users Cc: Paul Kapinos Subject: Re: [OMPI users] NAG Fortran 2018 bindings with Open MPI 4.1.2 Dear Jeff, I should like to point out that the NAG Fortran compiler is [and likely their developers are] the most picky and overly didactic Fortran compiler [developers] I know. (I worked tightly with more than 5 vendors and in dozens of versions, an I reported some 200 bugs to the early development stage of Mercurium Fortran compiler https://github.com/bsc-pm/mcxx and dozens to Intels 'ifort' - sorry for praising myself :-) In about 5 cases I was hard believing 'that is a bug in the NAG compiler!' because they did not compile a code accepted (and often working!) by all other compilers - intel, gfortran, Sun/Oracle studio, PGI... Then I tried to open a case by NAG (once or two times IIRC), and to read the f****g Fortran language standard, and in *all* cases - without exception! - the NAGs interpretation of the standard was the *right* one. (I cannot state that about gfortran and intel, by the way.) So these guys may be snarky, but they can Fortran, definitely. And if Open MPI bindings may be compiled by this compiler - they would be likely very standard-conforming. Have a nice day and a nice year 2022, Paul Kapinos On 12/30/21 16:27, Jeff Squyres (jsquyres) via users wrote: > Snarky comments from the NAG tech support people aside, if they could be a > little more specific about what non-conformant Fortran code they're referring > to, we'd be happy to work with them to get it fixed. > > I'm one of the few people in the Open MPI dev community who has a clue about > Fortran, and I'm *very far* from being a Fortran expert. Modern Fortran is a > legitimately complicated language. So it doesn't surprise me that we might > have some code in our configure tests that isn't quite right. > > Let's also keep in mind that the state of F2008 support varies widely across > compilers and versions. The current Open MPI configure tests straddle the > line of trying to find *enough* F2008 support in a given compiler to be > sufficient for the mpi_f08 module without being so overly proscriptive as to > disqualify compilers that aren't fully F2008-compliant. Frankly, the state > of F2008 support across the various Fortran compilers was a mess when we > wrote those configure tests; we had to cobble together a variety of > complicated tests to figure out if any given compiler supported enough F2008 > support for some / all of the mpi_f08 module. That's why the configure tests > are... complicated. > > -- > Jeff Squyres > jsquy...@cisco.com > > ________________________________________ > From: users <users-boun...@lists.open-mpi.org> on behalf of Matt Thompson via > users <users@lists.open-mpi.org> > Sent: Thursday, December 23, 2021 11:41 AM > To: Wadud Miah > Cc: Matt Thompson; Open MPI Users > Subject: Re: [OMPI users] NAG Fortran 2018 bindings with Open MPI 4.1.2 > > I heard back from NAG: > > Regarding OpenMPI, we have attempted the build ourselves but cannot make > sense of the configure script. Only the OpenMPI maintainers can do something > about that and it looks like they assume that all compilers will just swallow > non-conforming Fortran code. The error downgrading options for NAG compiler > remain "-dusty", "-mismatch" and "-mismatch_all" and none of them seem to > help with the mpi_f08 module of OpenMPI. If there is a bug in the NAG Fortran > Compiler that is responsible for this, we would love to hear about it, but at > the moment we are not aware of such. > > So it might mean the configure script itself might need to be altered to use > F2008 conforming code? > > On Thu, Dec 23, 2021 at 8:31 AM Wadud Miah > <wmiah...@gmail.com<mailto:wmiah...@gmail.com>> wrote: > You can contact NAG support at supp...@nag.co.uk<mailto:supp...@nag.co.uk> > but they will look into this in the new year. > > Regards, > > On Thu, 23 Dec 2021, 13:18 Matt Thompson via users, > <users@lists.open-mpi.org<mailto:users@lists.open-mpi.org>> wrote: > Oh. Yes, I am on macOS. The Linux cluster I work on doesn't have NAG 7.1 on > it...mainly because I haven't asked for it. Until NAG fix the bug we are > seeing, I figured why bother the admins. > > Still, it does *seem* like it should work. I might ask NAG support about it. > > On Wed, Dec 22, 2021 at 6:28 PM Tom Kacvinsky > <tkacv...@gmail.com<mailto:tkacv...@gmail.com>> wrote: > On Wed, Dec 22, 2021 at 5:45 PM Tom Kacvinsky > <tkacv...@gmail.com<mailto:tkacv...@gmail.com>> wrote: >> >> On Wed, Dec 22, 2021 at 4:11 PM Matt Thompson >> <fort...@gmail.com<mailto:fort...@gmail.com>> wrote: >>> >>> All, >>> >>> When I build Open MPI with NAG, I have to pass in: >>> >>> FCFLAGS"=-mismatch_all -fpp" >>> >>> this flag tells nagfor to downgrade some errors with interfaces to warnings: >>> >>> -mismatch_all >>> Further downgrade consistency checking of procedure >>> argument lists so that calls to routines in the same file which are >>> incorrect will produce warnings instead of error >>> messages. This option disables -C=calls. >>> >>> The fpp flag is how you tell NAG to do preprocessing (it doesn't >>> automatically do it with .F90 files). >>> >>> I also have to pass in a lot of other flags as seen here: >>> >>> https://github.com/mathomp4/parcelmodulefiles/blob/main/Compiler/nag-7.1_7101/openmpi/4.1.2.lua >>> >>> Now I hadn't yet tried NAG 7.1 with Open MPI because NAG 7.1 has a bug with >>> a library I depend on, but it does promise better F2008 support. To see >>> what happens, I tried myself and added --enable-mpi-fortran=all, but: >>> >>> checking if building Fortran 'use mpi_f08' bindings... no >>> configure: error: Cannot build requested Fortran bindings, aborting >>> >>> Unfortunately, the NAG Fortran guru I work with is off until the new year. >>> When he comes back, I might ask him about this. He might know something we >>> can do to make NAG happy with mpif08. >>> >> >> The very curious thing about this is that NAG 7.1 is that mpif08 >> configured properly with the macOS (Intel architecture) flavor of >> it. But as this thread seems to indicate, it barfs on Linux. Just >> an extra data point. >> > > I'd like to recall that statement, I was not looking at the config.log > carefully enough. I see this still, even on macOS > > checking if building Fortran 'use mpi_f08' bindings... no > > > -- > Matt Thompson > “The fact is, this is about us identifying what we do best and > finding more ways of doing less of it better” -- Director of Better Anna > Rampton > > > -- > Matt Thompson > “The fact is, this is about us identifying what we do best and > finding more ways of doing less of it better” -- Director of Better Anna > Rampton -- Dipl.-Inform. Paul Kapinos - High Performance Computing, RWTH Aachen University, IT Center Seffenter Weg 23, D 52074 Aachen (Germany) Tel: +49 241/80-24915
