recursive.mod problem

[Norman_K_]

Dear All

I have a library I am trying to port to ifort on MacOS, and about half way through, the following happens:

[ 47%] Building Fortran object CMakeFiles/common.dir/WR_RECORDER.f90.o

[ 48%] Building Fortran object CMakeFiles/common.dir/WRITE_HTML_TEST.f90.o

[ 48%] Building Fortran object CMakeFiles/common.dir/COMMON_MODS.f90.o

[ 48%] Building Fortran object CMakeFiles/common.dir/SPECIAL_CONSTANTS_subm.f90.o

Error copying Fortran module "recursive".  Tried "RECURSIVE.mod" and "recursive.mod".

make[2]: *** [CMakeFiles/common.dir/recursive.mod.stamp] Error 1

make[1]: *** [CMakeFiles/common.dir/all] Error 2

make: *** [all] Error 2

The slight problem is that I have no idea what this Fortran module "recursive" is!

On my Mac I am using CMake to create a make file which contains no reference to a recursive.mod.  I have no file called recursive.f90 or a module called recursive.

I do use small number of recursive routines, and many of these seem to have compiled just fine.

I have no idea what to do next, I am using

ifort (IFORT) 17.0.5 20170817

Thanks in advance

Norman

[Norman_K_]

Sorry about the formatting

[Juergen_R_R]

Might be that for some reason the module recursive failed to built, hence it could not be copied. 

[Norman_K_]

Dear Juergen

Thanks for the very prompt reply

Is there a Fortran system module called "recursive", should I be telling Cmake where to find it, and where is it likely to be?

N

[Juergen_R_R]

No, there is no system module called recursive. Recursive must be the name of one of your modules in the library that you try to build. 

[Norman_K_]

No I have no module by this name.

[Juergen_R_R]

The error message definitely comes from the cmake build system. So at least this one believes there is a module named recursive. I think that the automatic assessment of your Fortran dependencies failed. 

[Norman_K_]

If I can reproduce the problem in a smaller example I will submit it as a support request, but you are right, it may be Cmake struggling to understand the dependencies - interestingly there is no mention of a module called recursive.* in the output makefile.

Thanks

N

[Norman_K_ · Accepted solution]

OK I have sorted this out:

My code contained the statement (in the body of a submodule):

module recursive function blah(i)

and this was generating the problem with a module called "recursive"

In the Mac version, the problem goes away with a simple change to

recursive module function blah(i)

Please note that both versions have the originally anticipated effect in the Windows version of the ifort compiler

Please also note that the Mac version was quite happy with the interface declaring the function to be a module function and recursive in either order, the problem only arises in the submodule body.

[jimdempseyatthecove]

Steve,

Can you comment on the Fortran standards as it related to post #9 (problem statement)?

Jim Dempsey

[Lorri_M_Intel]

Hi Jim -

         I'm not Steve, although I used to play him on TV sometimes ... :-)

         Are you asking if the two declarations are considered, by the standard, to be the same?   I would say "Yes'.  Procedures defined by subprograms (Chapter 15.6.2 in the F2018 draft) are allowed a number of keywords as a prefix, and the order is not mandated.

        I thought the issue here was CMake, not ifort, am I misunderstanding?

                                   --Lorri

[Norman_K_]

Dear Lorri

After a lot of investigation, it turned out that the problem is completely an ifort for Mac problem and has nothing to do with Cmake. ifort for Windows does not show this issue either.

(I had originally suspected Cmake/make because of the message from ifort about a module called recursive, but this turns out to be ifort not understanding the statement described above. Juergen, in kindly trying to help, had sent me down what turned out to be a blind alley with a red herring at the end.)

Thanks

Norman

[jimdempseyatthecove]

The question I have is: does the standard state:

[keywords] "module function" name     (quotes indicates unbroken words)

and/or

"module [keywords] function" name

and/or

[keywords] "module [keywords] function" name

The IVF documentation (implies) "module function" (quotes indicates unbroken words).

Do you have a link to the TV show? ;)

Jim Dempsey

[Lorri_M_Intel]

"MODULE" is listed as one of the keywords, and the keywords are not ordered, so "recursive module" should be the same as "module recursive".

Should be.

[jimdempseyatthecove]

Taken to extreme ...

function real foo()   (I know it is [prefix [prefix]] function foo() )
none implicit

eh?

Jim Dempsey

[Steve_Lionel]

Yes, Lorri has often performed as a double for me on TV. It's an uncanny resemblance, almost as good as Ed Wood Jr.'s wife's chiropractor filling in for Bela Lugosi in "Plan 9 from Outer Space."

[clodius__william]

Note I had a similar problem involving CMAKE and interfaces for recursive module functions on my Mac, but in this case the compiler was gfortran. From the symptoms I came to believe that the problem was not with gfortran (or fort for the poster), but rather with CMAKE. CMAKE has a crude Fortran parser in order to determine the module dependencies used to structure the Makefiles it creates.  In this case when it sees module starting a line it appears to think that the next word following module has to be the name of a module, and it sets up the makefiles expecting that the name.mod file will be generated. This worked until submodules were introduced in F2008, that in turn resulted in the use of module as a keyword in some interface blocks.