forums.silverfrost.com

[jlb]

Some recipes (Numerical Recipes in Fortran 90: Volume 2, by W.H. Press et al.) use a subsidiary routine (xxx_private) for sharing / hiding data. The principle is given in the following example, without any original calculation for copyright reasons.
In its original version, the example fails at execution time with "access violation, the instruction at address xx attempted to write to an illegal location", after the value of j having been corrrectly displayed (j in mcof: 3).

[PaulLaidler]

jlb

This appears to be a fault in FTN95 and I have made a note of this.

The statement ordering is not correct at line 16 but that makes no difference to the outcome.

[jlb]

Paul

Thanks for your attentive reviewing. I corrected this line in the source code above, sorry for the mistake, the interface for mmin doesn't seem to be required though.

[PaulLaidler]

I have carried out an initial investigation for this code and fixed a compilation error for 64 bit FTN95. I now have executables that fail at runtime for both 32 and 64 bit compilation. I get the same outcome with gFortran.

So the immediate question is, is this a bridge too far? If anyone has other compilers and is willing to run a test then please test with the following...

[mecej4]

Consider the statement

CALL mmin(fg,3).

in the code posted by Paul.

The second argument, namely, the constant 3, corresponds to the dummy argument j of MMIN. Inside subroutine MMIN, an assignment is made to j. Thus, an attempt is made to write into a non-writeable argument.

Depending on the compiler, this is very likely to cause an access violation.

The code posted by JLB, however, causes FTN95 to generate bad code (32-bit, stops on access violation) or fail to compile (64-bit, AMD backend failure). This code runs normally when compiled with other compilers.

[mecej4]

All those interfaces and indirections (misdirections, perhaps?) in the code attributed to Numerical Recipes make me dizzy. Rewritten in F77, the code is, essentially, the same as

[PaulLaidler]

mecej4

Thanks for the information. That's very useful.

[jlb]

Some complemental informations. First for the anecdote, William H. Press et al. have also published "Numerical Recipes in Fortran 77". When stripping the calculations from the code, the remaining structure corresponds to the code proposed above by mecej4, with two minimal differences: no use of IMPLICIT NONE and no EXTERNAL declaration of funcs in subroutine mmin, as in the following.

[LitusSaxonicum]

The obfuscation of code for various reasons is better known to some programmers than to others. In my case, I prefer things to be straightforward so that I can understand what I did when I return to it after a gap of months, years or even decades. It's a matter of taste and priorities, I suppose.

In the case illustrated, even Mecej4 cannot make head nor tail of it, and I'm not even going to try. I do wonder if the eponymous William H. Press et al. still understand it?

However, Leo Colston's view* that while the past is a foreign country where they do things differently applies to the difference between Fortrans 77 and 90 et seq., it has reinforced my own view that in some respect they do things rather better there.

Eddie

* Or L. P. Hartley's, if you prefer.

[jlb]

Regardless of the beauty of the code or the meaningfulness of doing so like the authors of the Numerical Recipes, the sample of principle runs normally - according to mecej4 - when compiled with other compilers, with FTN95 not.

[PaulLaidler]

This failure has now been fixed for the next release of FTN95.

[jlb]

Paul

Thanks a lot for the investigation and the fixing of this weird and quite particular issue.