Re: subroutines as arguments

<david.turner3@xxxxxxxxxxx> wrote:

To wit, is the following "legal" per the Fortran standard?

subroutine foo(x)
....
call bar(x,foo)

No.... Well... I suppose there might be an obscure technicality that
might make it legal in an obscure case, but the case would, by
definition, be completely useless and thus only of academic interest.
That would be the case where bar never ended up invoking the subroutine
passed to it. But in that case, there wasn't much point in passing it.
I'm not entirely sure of that particular nitpicky point without spending
more time than I want to in digging. Even if it is arguably technically
legal, a compiler would certainly be well justified in warning that it
was highly suspect. But absolutely for sure it is not legal if bar ever
ends up invoking foo.

This is exactly what recursive is about - foo getting called while an
instance of foo is already active. It does not matter that the second
call to foo would occur indirectly from bar instead of directly from
foo. It is still recursive and thus needs the recursive attribute.

Compilers are not required to catch illegal recursive calls. Indeed,
some cases would be impractical to detect at compile time. Also, some
compilers might have extensions that allow nonstandard recursive calls.
Other compilers might not have it as a deliberate extension, but might
just happen to work. Also, sucessful compilation does not guarantee
sucessfull execution. The short version of all that is that all bets are
off when you have this particular nonstandard practice.

It has nothing in particular to do with being a subroutine. All the same
things apply to functions. But one feature of functions is quite likely
to be confusing you.

On those machines/compilers where the above doesn't help,
changing "foo" from a subroutine to a function eliminates the errors.

It might have eliminated the compilation errors, but did you try to
actually run it? You might be in for a bit of a surprise because I bet
it does nothing even close to what you think it does. If you do

function foo(...)
...
call bar(foo)

then what gets passed to bar is not the function foo. What gets passed
to bar is instead the result variable, which is also named foo, but is
just a variable instead of the function. If foo isn't resursive, that's
the only potentially useful thing of that name that could be passed
anyway. If foo is recursive, then it could make sense to pass either the
function or the result variable. But if foo is recursive, then it is
required to have a RESULT clause to give the result variable a different
name from the function, thus eliminating any such ambiguity.

So, is this a compiler bug I'm running into, or is this not legal
Fortran? More details about machines and compilers upon
request.

It is just not legal Fortran. No, compiler details aren't interesting in
this case. As I said above, all bets are off with this code; a compiler
can do anything it like with it, and need not even be consistent.

The correct fix is to add the recursive attribute.

Well... I suppose the one set of compiler details that might be helpful
would be the compilers where adding recursive did *NOT* fix it. Those
are the compilers that might merit suspicion, except that...

Well, if they are f77 compilers, then that's very different. F77 doesn't
allow recursion at all. You appear to have a few f90-isms in the code,
but it is at least possible that you are using an f77 compiler that has
those f90 features.

I would also want to see the exact code and exact error message before
too stringly suspecting a compiler bug. Describing that you added
recursive isn't enough. I'd want to see exactly how you did it. And I'd
want to see the error message and the exact code that produced it to
make sure that you didn't hit some different error.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.