Program on old fortran IV

Program on old fortran IV

[Joao Martins Correia]

Dear Gcc Helpers

I recovered an old scientific program code written in Fortran IV.
Still using hollerith assignments - which I think I understand, I can compile it with the many warnings
regarding essentially 3 things

1- hollerith

2- “do" cycles indexed to an active command line instead of “enddo" or “continue”, e.g.

do	10 i=1,n
 		x=x+1
10	y=y+1

3-“if” of the type

 If (n) 10,20,30

All of this can be cleaned, but I have the feeling that in spite of the warnings the compiler still treats these 3 warnings correctly, since I could test it
with coherent results.

The program starts running, properly, reads input files and execute some routines, but then gets stuck with strange huge
numbers that have no apparent reason to be there.
The problem is in fact that there are no assignment of variable types and there are many commons with different variable names
that contribute to the confusion when debugging. Setting “implicit none” creates too many errors, since sometimes is not easy
to assign the type of the variable on a code with 30 routines and more than 5000 lines.

I am considering reviewing it fully, but first would like to know if there is some options that could help emulating
an older compiler for fortran IV. In the moment the fortran routines have type .f 

Thanks anyway

Cheers

João Correia

Re: Program on old fortran IV

[Tim Prince]

On 4/29/2020 9:37 AM, Joao Martins Correia wrote:
> Dear Gcc Helpers
>
> I recovered an old scientific program code written in Fortran IV.
> Still using hollerith assignments - which I think I understand, I can compile it with the many warnings
> regarding essentially 3 things
>
> 1- hollerith
>
> 2- “do" cycles indexed to an active command line instead of “enddo" or “continue”, e.g.
>
> do	10 i=1,n
>  		x=x+1
> 10	y=y+1
>
> 3-“if” of the type
>
>  If (n) 10,20,30
>
> All of this can be cleaned, but I have the feeling that in spite of the warnings the compiler still treats these 3 warnings correctly, since I could test it
> with coherent results.
>
> The program starts running, properly, reads input files and execute some routines, but then gets stuck with strange huge
> numbers that have no apparent reason to be there.
> The problem is in fact that there are no assignment of variable types and there are many commons with different variable names
> that contribute to the confusion when debugging. Setting “implicit none” creates too many errors, since sometimes is not easy
> to assign the type of the variable on a code with 30 routines and more than 5000 lines.
>
> I am considering reviewing it fully, but first would like to know if there is some options that could help emulating
> an older compiler for fortran IV. In the moment the fortran routines have type .f 
>
> Thanks anyway
>
> Cheers
>
> João Correia

Those old programs often made assumptions such as those covered by
gfortran -fno-automatic -finit-local-zero .  There was no portability or
standards checking in most compilers, and chances are your program was
never analyzed for those.  I don't think gfortran carried over the
-fone-trip option from g77, another assumption which many people
considered erroneously to be part of f66 standard.   You may be stuck
with setting implicit none and weeding out errors.


-- 
Tim Prince

Re: Program on old fortran IV

[Bob Wilkinson]

On Wed, Apr 29, 2020 at 01:37:25PM +0000, Joao Martins Correia wrote:
> Dear Gcc Helpers
> 
> I recovered an old scientific program code written in Fortran IV.
> Still using hollerith assignments - which I think I understand, I can compile it with the many warnings
> regarding essentially 3 things
> 
> The program starts running, properly, reads input files and execute some routines, but then gets stuck with strange huge
> numbers that have no apparent reason to be there.
> The problem is in fact that there are no assignment of variable types and there are many commons with different variable names
> that contribute to the confusion when debugging. Setting “implicit none” creates too many errors, since sometimes is not easy
> to assign the type of the variable on a code with 30 routines and more than 5000 lines.

It is many years since I did any FORTRAN programming, but I vaguely
remember that implicit none could be used on a subroutine by
subroutine basis (though that is probably compiler-dependent).

If this works for you, it may make your job easier. I do not like
implicit ...

Bob
-- 
"We are in the beginning of a mass extinction, and all you can talk
about is money and fairy tales of eternal economic growth."
  - Greta Thunberg

Re: Program on old fortran IV

[Joao Martins Correia]

Dear Bob


Many thanks for answering.
The problem is that it is difficult to identify the right type of variables they use without going trough the complexity of the program …
They are mixing integer with real all the time and no respect for precision ...
I think that I have no other way to go than the painful one, line by line.

Thanks again and Best regards

JG



> On 30Apr, 2020, at 16:59, Bob Wilkinson <bob.wilkinson@cristie.com> wrote:
> 
> On Wed, Apr 29, 2020 at 01:37:25PM +0000, Joao Martins Correia wrote:
>> Dear Gcc Helpers
>> 
>> I recovered an old scientific program code written in Fortran IV.
>> Still using hollerith assignments - which I think I understand, I can compile it with the many warnings
>> regarding essentially 3 things
>> 
>> The program starts running, properly, reads input files and execute some routines, but then gets stuck with strange huge
>> numbers that have no apparent reason to be there.
>> The problem is in fact that there are no assignment of variable types and there are many commons with different variable names
>> that contribute to the confusion when debugging. Setting “implicit none” creates too many errors, since sometimes is not easy
>> to assign the type of the variable on a code with 30 routines and more than 5000 lines.
> 
> It is many years since I did any FORTRAN programming, but I vaguely
> remember that implicit none could be used on a subroutine by
> subroutine basis (though that is probably compiler-dependent).
> 
> If this works for you, it may make your job easier. I do not like
> implicit ...
> 
> Bob
> -- 
> "We are in the beginning of a mass extinction, and all you can talk
> about is money and fairy tales of eternal economic growth."
>  - Greta Thunberg