Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

recursive.mod problem

Norman_K_
New Contributor I
155 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
155 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

16 Replies
Norman_K_
New Contributor I
155 Views

Sorry about the formatting

Juergen_R_R
Valued Contributor I
155 Views

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

Norman_K_
New Contributor I
155 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

Juergen_R_R
Valued Contributor I
155 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. 

Norman_K_
New Contributor I
155 Views

No I have no module by this name.

Juergen_R_R
Valued Contributor I
155 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. 

 

Norman_K_
New Contributor I
155 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

Norman_K_
New Contributor I
156 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

jimdempseyatthecove
Black Belt
155 Views

Steve,

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

Jim Dempsey

 

Lorri_M_Intel
Employee
155 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

 

         

 

Norman_K_
New Contributor I
155 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

jimdempseyatthecove
Black Belt
155 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

Lorri_M_Intel
Employee
155 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.

 

 

jimdempseyatthecove
Black Belt
155 Views

Taken to extreme ...

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

eh?

Jim Dempsey

Steve_Lionel
Black Belt Retired Employee
155 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."

clodius__william
Beginner
155 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. 

Reply