views:

761

answers:

4

When writing and calling pure subroutines in Fortran 90 using gfortran, how do I find out why the compiler emits this error?

Error: Subroutine call to XXXX at (1) is not PURE

I'll try to pose my question as specifically as I can while at the same time being general enough to be useful to others, so I'll avoid pasting in my actual code and instead will sketch what happened.

I understand there are various rules about pure procedures in Fortran 90, which I think basically boil down to not permitting side-effects in either functions or subroutines, and not permitting changes to subroutine parameters declared with intent(in). I've a series of subroutines which initially were not declared to be pure, and whose parameters didn't have declared intent, but which nevertheless didn't perform side-effects. First, I changed all parameter declarations to have explicitly-declared intent, either in, out, or inout. Then, I declared all the subroutines to be PURE. Naturally, many errors occurred on the first attempt, but the compiler told me what the errors were (such-and-such parameter with intent(in) is being modified, for example), so one-by-one I fixed them all.

There are calls among these procedures, however, and so now I still get many errors of the form shown above: Subroutine call to XXXX at (1) is not PURE. What I don't understand is why the call is not pure. I've done everything I can think of to make XXXX pure, but the compiler still thinks it isn't.

So my question --rephrased-- is: how do I get gfortran to tell me WHY it thinks XXXX is not pure?

+2  A: 

Probably because it's not marked as PURE. The fact that a subroutine is pure is not related to what it does or not with its arguments, but to the fact that it's declared as PURE. (Of course, once declared as pure, what you do with the arguments comes into play and is checked.)

FX
Yeah, but that's the thing. I have marked them as PURE.
David A. Ventimiglia
+1  A: 

I'll try to be more clear about my question in my answer. I was reluctant to post my code for these reasons.

  1. I don't expect other people to debug my code for me. That's way too much to ask.
  2. I wanted my question and its answer(s) to be more general.
  3. It seemed gfortran was telling me my subroutines were not PURE, but it wasn't telling me WHY it considered them not to be pure.

So I hoped to find out, not how to fix my code and make the procedures PURE, but rather to find out how to coax more useful information from gfortran, in order to help me fix my code.

Two things that I did helped fulfill these goals. Of course, your results may vary.

  1. Added this flag to the gfortran command-line: -fmax-errors=100 Of course, I'd done that earlier, but it still seemed not to tell me what I needed to know.
  2. Placed all the PURE subroutines in the library I'm working on, into a MODULE (which my client code then USEd). Since this library's ancestry is as Fortran77, originally, this was not the case. Not sure why (which is why I stress that "your results may vary"), but after doing this more useful error messages appeared which allowed me to track down the remaining impurities.

It's kind of a nebulous question, I know, and I'm not sure how useful it will be. Still, thanks to everyone who read, commented on, and added answer(s).

David A. Ventimiglia
+1 For coming back and explaining what worked for you.
ire_and_curses
A: 

Hi David!

I am Fortran beginner and last week I reached chapter about Fortran procedures in my book. May be I'm not right but... So if you will excuse my English there are some remarks:

  1. It's not good style to declare subroutines pure. It's advisable for functions.
  2. Pure procedures were introduced in Fortran 95 standard. Not in Fortran 90.
  3. You problem probably arises from item C1270 in (Fortran 2003 Standard) which read as follows:

If a procedure that is neither an intrinsic procedure nor a statement function is used in a context that requires it to be pure, then its interface shall be explicit in the scope of that use. The interface shall specify that the procedure is pure.

I hope that it is useful information.

kemiisto
Hi Kemiisto! Thanks for the comments. Just a few clarifications.Whether it is or is not good style to have pure subroutines, I'm adapting library code, which I didn't write and which is largely composed of subroutines. I'm just working with what I was given.As for the requirement that a pure procedure have an explicit interface, I read that as well but wondered how that requirement is to be met. The library I was handed comprised a set of subroutines, not contained in a module. Part of my "solution" was to put them into a module. Did that give them explicit interfaces? I don't know.
David A. Ventimiglia
+2  A: 

"Placed all the PURE subroutines in the library I'm working on, into a MODULE (which my client code then USEd). ...... Not sure why ....., but after doing this more useful error messages appeared which allowed me to track down the remaining impurities."

Placing the subroutines into a module and then using them makes the interface explicit. This allows the compiler to check agreement between the call and the subroutine and generate error messages if there is a discrepancy. Very useful, so placing subroutines and functions into modules good practice.

The other way of making an interface explicit is to write an interface, but that is extra work and an extra step to get wrong.

There is a long list of requirements on pure subroutines/functions. If you have Fortran 95/2003 Explained by Metcalf, Reid and Cohen, see section 6.10. For example, no "save" variables, no stop statement, no IO on external file, ...

You can also try other compilers to see if their error message is more helpful. Other free ones, depending on OS, include g95 and Sun Studio.

M. S. B.
Thanks, M.S.B. Yes, it seemed the ultimate solution was to place the subroutines into their own module which, as I reflected on it in hindsight, is exactly what would grant them explicit interfaces.
David A. Ventimiglia