Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

recursive.mod problem

Norman_K_
New Contributor I
752 Views

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

0 Kudos
1 Solution
Norman_K_
New Contributor I
752 Views

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.

 

View solution in original post

0 Kudos
16 Replies
Norman_K_
New Contributor I
752 Views

Sorry about the formatting

0 Kudos
Juergen_R_R
Valued Contributor I
752 Views

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

0 Kudos
Norman_K_
New Contributor I
752 Views

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

0 Kudos
Juergen_R_R
Valued Contributor I
752 Views

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. 

0 Kudos
Norman_K_
New Contributor I
752 Views

No I have no module by this name.

0 Kudos
Juergen_R_R
Valued Contributor I
752 Views

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. 

 

0 Kudos
Norman_K_
New Contributor I
752 Views

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

0 Kudos
Norman_K_
New Contributor I
753 Views

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.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
752 Views

Steve,

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

Jim Dempsey

 

0 Kudos
Lorri_M_Intel
Employee
752 Views

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

 

         

 

0 Kudos
Norman_K_
New Contributor I
752 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
752 Views

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

0 Kudos
Lorri_M_Intel
Employee
752 Views

"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.

 

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
752 Views

Taken to extreme ...

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

eh?

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
752 Views

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."

0 Kudos
clodius__william
Beginner
752 Views

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. 

0 Kudos
Reply