g77 plans - support for automatic, .eq. for logicals, etc?

g77 plans - support for automatic, .eq. for logicals, etc?

[Harvey J. Stein]

We're still using f2c because it's more friendly for our code.
Specifically:

1. The AUTOMATIC keyword for forcing allocation of specified variables
   on the stack instead of statically is not supported by g77.
2. G77 requires .EQV. & .NEQV. to be used for comparing logicals,
   whereas most other Fortran compilers accept the use of .EQ. and
   .NE. without comment.
3. G77 chokes on certain implicit do loops in DATA statements that
   other Fortran compilers accept without comment.
4. f2c + my f2c-stabs package works better under gdb (inside of emacs)
   for viewing variables than g77 with gdb.

I'm not sure if this is a complete list, but it's most of the reason
why we're unable to switch to g77 from f2c.

Are there any plans for addressing these points, or are we forced to
either keep using f2c?  BTW, because of compilation standards on other
platforms (not to mention the size of the changes required), we can't
solve 1 by compiling with the flag to make all variables automatic
except for those mentioned in a STATIC line.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il

Re: g77 plans - support for automatic, .eq. for logicals, etc?

[craig]

>We're still using f2c because it's more friendly for our code.
>Specifically:
>
>1. The AUTOMATIC keyword for forcing allocation of specified variables
>   on the stack instead of statically is not supported by g77.

Don't recall hearing about that one before.  But, I'll add it to the
list of extensions not supported.  (BTW, why do you actually need it?
g77 already does default to allocating most local variables to the
stack anyway, a la `f2c -a'.  If you need recursion, RECURSIVE is already
on the list of extensions not supported, for what that's worth.  Of
course, if you need it just to support old code you can't change,
then for now you need either a preprocessor to remove it or a
new version of g77 that supports it.)

>2. G77 requires .EQV. & .NEQV. to be used for comparing logicals,
>   whereas most other Fortran compilers accept the use of .EQ. and
>   .NE. without comment.

The g77 docs cover this very thoroughly, I think.  Basically, no code
should be using it.  Code that does can be compiled via g77 using
a command-line option, though I think for only one particular
interpretation of what LOGICAL .EQ. LOGICAL actually *means*.  (As
the g77 docs explain, there are two interpretations vis-a-vis
operator precedence.)

>3. G77 chokes on certain implicit do loops in DATA statements that
>   other Fortran compilers accept without comment.

For example?  (My guess: repeated initialization of the same array
element, which is disallowed by the standard, and which might be
tricky to get g77 to *elegantly* allow, though a kludgey job could
probably be quickly done.)

>4. f2c + my f2c-stabs package works better under gdb (inside of emacs)
>   for viewing variables than g77 with gdb.

g77 has lots of known problems vis-a-vis debugging, indeed.

>I'm not sure if this is a complete list, but it's most of the reason
>why we're unable to switch to g77 from f2c.
>
>Are there any plans for addressing these points, or are we forced to
>either keep using f2c?  BTW, because of compilation standards on other
>platforms (not to mention the size of the changes required), we can't
>solve 1 by compiling with the flag to make all variables automatic
>except for those mentioned in a STATIC line.

(I think you mean SAVE line.)

At the moment, there is zero funding for any further work on g77, and
that has been the case for well over six months, AFAIK.  There is
ongoing improvement of the egcs version of g77, but to date much of
that has been bug-fixing and, on my own part, huge-backlog-catch-up.
It's not yet clear whether/when adding F90 and non-F90 extensions will
be addressed.

        tq vm, (burley)

g77 plans - support for automatic, .eq. for logicals, etc?

[Harvey J. Stein]

We're still using f2c because it's more friendly for our code.
Specifically:

1. The AUTOMATIC keyword for forcing allocation of specified variables
   on the stack instead of statically is not supported by g77.
2. G77 requires .EQV. & .NEQV. to be used for comparing logicals,
   whereas most other Fortran compilers accept the use of .EQ. and
   .NE. without comment.
3. G77 chokes on certain implicit do loops in DATA statements that
   other Fortran compilers accept without comment.
4. f2c + my f2c-stabs package works better under gdb (inside of emacs)
   for viewing variables than g77 with gdb.

I'm not sure if this is a complete list, but it's most of the reason
why we're unable to switch to g77 from f2c.

Are there any plans for addressing these points, or are we forced to
either keep using f2c?  BTW, because of compilation standards on other
platforms (not to mention the size of the changes required), we can't
solve 1 by compiling with the flag to make all variables automatic
except for those mentioned in a STATIC line.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il

Re: g77 plans - support for automatic, .eq. for logicals, etc?

[craig]

>We're still using f2c because it's more friendly for our code.
>Specifically:
>
>1. The AUTOMATIC keyword for forcing allocation of specified variables
>   on the stack instead of statically is not supported by g77.

Don't recall hearing about that one before.  But, I'll add it to the
list of extensions not supported.  (BTW, why do you actually need it?
g77 already does default to allocating most local variables to the
stack anyway, a la `f2c -a'.  If you need recursion, RECURSIVE is already
on the list of extensions not supported, for what that's worth.  Of
course, if you need it just to support old code you can't change,
then for now you need either a preprocessor to remove it or a
new version of g77 that supports it.)

>2. G77 requires .EQV. & .NEQV. to be used for comparing logicals,
>   whereas most other Fortran compilers accept the use of .EQ. and
>   .NE. without comment.

The g77 docs cover this very thoroughly, I think.  Basically, no code
should be using it.  Code that does can be compiled via g77 using
a command-line option, though I think for only one particular
interpretation of what LOGICAL .EQ. LOGICAL actually *means*.  (As
the g77 docs explain, there are two interpretations vis-a-vis
operator precedence.)

>3. G77 chokes on certain implicit do loops in DATA statements that
>   other Fortran compilers accept without comment.

For example?  (My guess: repeated initialization of the same array
element, which is disallowed by the standard, and which might be
tricky to get g77 to *elegantly* allow, though a kludgey job could
probably be quickly done.)

>4. f2c + my f2c-stabs package works better under gdb (inside of emacs)
>   for viewing variables than g77 with gdb.

g77 has lots of known problems vis-a-vis debugging, indeed.

>I'm not sure if this is a complete list, but it's most of the reason
>why we're unable to switch to g77 from f2c.
>
>Are there any plans for addressing these points, or are we forced to
>either keep using f2c?  BTW, because of compilation standards on other
>platforms (not to mention the size of the changes required), we can't
>solve 1 by compiling with the flag to make all variables automatic
>except for those mentioned in a STATIC line.

(I think you mean SAVE line.)

At the moment, there is zero funding for any further work on g77, and
that has been the case for well over six months, AFAIK.  There is
ongoing improvement of the egcs version of g77, but to date much of
that has been bug-fixing and, on my own part, huge-backlog-catch-up.
It's not yet clear whether/when adding F90 and non-F90 extensions will
be addressed.

        tq vm, (burley)