Errors compiling old FORTAN CM code

Errors compiling old FORTAN CM code

Hi there,

I'm a total beginner with FORTRAN, I used to code in VB. I'm trying to compile this code : http://www.nwd-wc.usace.army.mil/report/ssarr.htm into a 64bit program. I successfully compiled the code (with few modifications) in the release mode, but the program crash at execution.

I'm now trying to complile it in debug mode, in order to understand what is appening. When compiling the original code (with only changes to the original "$INCLUDE:" statements now "INCLUDE "), I get plenty of those errors:

Error #5560: Subscript #1 of the array FCN has value 7 which is greater than the upper bound of 4

Error #6633: The type of the actual argument differs from the type of the dummy argument.

Error #7983: The storage extent of the dummy argument exceeds that of the actual argument.

Error #7425: A dot (.) is invalid in a format list in this context. code : 380 FORMAT ( 59H ELEVATION VS. PERCENT OF AREA BELOW THAT ELEVATION / 5(F11.2,F5.1))

Error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element.

Error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: <FORMAT_ELEMENT> <FORMAT_INTEGER> < ) <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> ... code: 810 FORMAT (19H ERROR1101 STATION ,2A4,35H IS NOT IN FILE-IGNORE THIS1STATION)

Can anyone tell me if what I'm trying to do is possible? If so, can anyone give me a quick walkthrough to solve those errors? I know conversion of old codes can be difficult, and since I'm new to FORTRAN, I really need help!

Thank you very much.

Mat

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Newer compilers do a better job of checking improper programming practices of the past. The proper response to the messages that you reported is to fix the code appropriately.

If you are absolutely sure that the code was correct despite running afoul of Fortran Standard requirements, you may use a utility such as Fsplit to split your source code into a number of files each containing a single subprogram. You then then compile them separately, and do a final link step. This way, the compiler only gets to see one subprogram source at a time, and cannot do the proper cross checks that.

With regard to the Format statement, it would be best to convert the hoary Hollerith strings to quoted strings, unless you want to get cross-eyed by counting too many sub-string lengths by visual inspection.

Errors 1,2,3 and 5 are being caught by the improved diagnostic capability of the Intel compiler. The code you're using is not legal Fortran, but may have been written so that the violations didn't matter. Without seeing the code, I can't tell you what to change. You didn't say how it "crashed", but the errors here are certainly the kind that can lead to run-time errors.

For the two errors relating to FORMAT statements, I'd need to see the actual source file to say exactly what is going on. I will download the source and see what I can find.

Steve - Intel Developer Support

Which version of this code are you using?  SSARR or SSARR 2000?

Steve - Intel Developer Support
Best Reply

Ok, probably SSARR.

Wow, is this code AWFUL! 

The FORMAT problems are interesting. The format item that begins with 59H is called a "Hollerith format item" - it means that the next 59 characters are interpreted as a string. Here, though, the line is continued and the first line doesn't go all the way to column 72. The question is - do you count the missing characters up to 72 or not? The 59 count assumes that you do count these, but if you do that then there are extra blanks in the text. The errors can be removed by setting the project property Fortran > Language > Pad Fixed Form Source Lines to Yes. This will allow the code to compile, but the file output will look strange.

You can eliminate reporting of many of the other errors by setting Fortran > Diagnostics > Check Routine Interfaces to No, but this just hides the errors which could still cause bad results at runtime. Even this won't help with the blatant out-of-bounds array references and attempts to compare character strings with integers.  Whoever wrote this code took wild liberties with correctness and took advantage of MS Fortran's poor diagnostic abilities.

In my opinion, you should not trust any answers this program gives you. Maybe some of the errors are harmless, but there are so many and it would take extensive analysis to figure out which ones are ok to ignore and which aren't.

Steve - Intel Developer Support

Yes... SSARR...

Thank you all for those responses. As a VB hobbyist, I'm glad to see that FORTRAN codes are normally better structured. The hint on Hollerith format also resolved one of the interrogation.

The program crashed with the following output :

forrt1: severe <64> : input conversion error, unit -5, file internal formatted Re

ad

then a table without any avluable info

kernell32.dll

ntdll.dll

Seems like it comes from stange conversions. I'm thinking about stopping trying...

Ok - that error means that there was either a READ from a character string or, possibly, a DECODE (old, non-standard syntax) statement that does the same thing. The contents of the string were not valid for the type of data being read.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today