Recursive subroutine with multiple calls

[eos_pengwern]

Hello,

I have a recursive subroutine which is called from a 'main' program, and which within its own source code calls itself on four separate occasions.

If I put the recursive subroutine into a project by itself, it compiles with no errors.

If I put the recursive subroutine into the same project as the 'main' program, then during the compilation an error is flagged in the recursive subroutine's source code for the second, third and fourth occurrences of it calling itself. The error message is "The same named entity from different modules and/or program units cannot be referenced". No error message is given for the first occurrence.

If I comment-out all except the first occurrence, then the whole project compiles with no errors.

Please can you make sense of this for me? I've tried using the recursive subroutine both within a module and outside a module, and it makes no difference. The subroutine is wholly self-contained and does not rely on any shared data (i.e. all the variables it needs are passed by reference through its arguments), so there's no actual need for it to be in a module.

[TimP]

If this happens with the current 10.1 compiler, with correct RECURSIVE syntax, please submit a problem report on premier.intel.com. Does it make a difference if you disable inter-procedural optimizations?
Such a report on this forum is more interesting if you give an actual example.

[eos_pengwern]

Thank you Tim; I guess I wanted to check that this wasn't standard Fortran behavior (for some unexpected reason) before pointing the finger at the compiler.

As it happens, I had been trying to compile in 'debug' mode, but your suggestion re. interprocedural optimizations made me wonder if this was in fact the problem. When I compiled the project in 'release' mode (using the default settings) it completed without error.

So it looks like it is in fact a compiler problem (since I am indeed in V10.1), and I shall switch forums.

[Steven_L_Intel1]

The message you're seeing is not related to optimization - it comes from the compiler's parsing and semantic analysis. The difference you're seeing between debug and release builds is that the debug build has interface generation and checking turned on and the release configuration does not.

I've seen a bug related to this option with the symptom you report, but I can't say, without seeing your test case, if in fact it is a compiler bug. It may be your coding error that the compiler is correctly diagnosing with the additional information.

Please submit an issue to Intel Premier Support and attach a ZIP of your project with sources so that we can take a look.

[eos_pengwern]

Thank you, I have done so. In fact, I've realized that when I successfully compiled the recursive subroutine in a project on its own, I must have overlooked the 'release' setting because that also does not work when in debug mode.

In fact, I found that even the following trivial code will compile in release mode but not in debug mode (unless I comment out the additional calls):

recursive subroutine factorial(x,y)integer :: x, y, zif (x.le.1) then
    y=1else    call factorial(x-1,y)
    y=y * xend if! Just for fun we'll call it a few more times, but do nothing with! the resultscall factorial(x-1,z)call factorial(x-1,z)call factorial(x-1,z)end

[Steven_L_Intel1]

It compiles fine for me - which compiler version do you have? Can you post the buildlog.htm from your Debug folder?

[eos_pengwern]

I'm using the latest, greatest V10.1.013; here's the contents of buildlog.htm:

Compiling with Intel Fortran Compiler 10.1.013 [IA-32]...
ifort /nologo /Zi /Od /gen-interfaces /warn:interfaces /module:"Debug" /object:"Debug" /traceback /check:bounds /libs:dll /threads /dbglibs /c /Qvc8 /Qlocation,link,"C:Program FilesMicrosoft Visual Studio 8VCin" "C:Documents and SettingsStephen J. MorrisMy DocumentsVisual Studio 2005ProjectsRecursionRecursionSource1.F90"
C:Documents and SettingsStephen J. MorrisMy DocumentsVisual Studio 2005ProjectsRecursionRecursionSource1.F90(15) : Error: The same named entity from different modules and/or program units cannot be referenced.   [FACTORIAL]
    call factorial(x-1,z)
---------^
C:Documents and SettingsStephen J. MorrisMy DocumentsVisual Studio 2005ProjectsRecursionRecursionSource1.F90(16) : Error: The same named entity from different modules and/or program units cannot be referenced.   [FACTORIAL]
    call factorial(x-1,z)
---------^
C:Documents and SettingsStephen J. MorrisMy DocumentsVisual Studio 2005ProjectsRecursionRecursionSource1.F90(17) : Error: The same named entity from different modules and/or program units cannot be referenced.   [FACTORIAL]
    call factorial(x-1,z)
---------^
compilation aborted for C:Documents and SettingsStephen J. MorrisMy DocumentsVisual Studio 2005ProjectsRecursionRecursionSource1.F90 (code 1)


Recursion - 4 error(s), 0 warning(s)

[Steven_L_Intel1]

Ok, I see it now. This happens the second time you compile it! It is a problem with the automatic interface checking - it should not check for a generated interface for a call to the containing routine.

I will pass this on to the developers. You can turn off "Check routine interfaces" in the Diagnostics property page if you want to avoid the problem.

[Steven_L_Intel1]

Hmm, it's more complicated than that - the first call is ok, but the three extras are flagged. What the difference is, I don't know...

[Steven_L_Intel1]

If you submit an issue on this to Intel Premier Support, please reference T82170-CP.

[eos_pengwern]

I've already submitted it, but I'll notify the person dealing with it of the reference.

Thanks very much.