* g77 plans - support for automatic, .eq. for logicals, etc? @ 1999-03-11 2:26 Harvey J. Stein [not found] ` < m21ziwgw5u.fsf@blinky.bfr.co.il > 1999-03-31 23:46 ` Harvey J. Stein 0 siblings, 2 replies; 4+ messages in thread From: Harvey J. Stein @ 1999-03-11 2:26 UTC (permalink / raw) To: egcs; +Cc: hjstein 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: < m21ziwgw5u.fsf@blinky.bfr.co.il >]
* Re: g77 plans - support for automatic, .eq. for logicals, etc? [not found] ` < m21ziwgw5u.fsf@blinky.bfr.co.il > @ 1999-03-11 8:02 ` craig 1999-03-31 23:46 ` craig 0 siblings, 1 reply; 4+ messages in thread From: craig @ 1999-03-11 8:02 UTC (permalink / raw) To: hjstein; +Cc: 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) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: g77 plans - support for automatic, .eq. for logicals, etc? 1999-03-11 8:02 ` craig @ 1999-03-31 23:46 ` craig 0 siblings, 0 replies; 4+ messages in thread From: craig @ 1999-03-31 23:46 UTC (permalink / raw) To: hjstein; +Cc: 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) ^ permalink raw reply [flat|nested] 4+ messages in thread
* g77 plans - support for automatic, .eq. for logicals, etc? 1999-03-11 2:26 g77 plans - support for automatic, .eq. for logicals, etc? Harvey J. Stein [not found] ` < m21ziwgw5u.fsf@blinky.bfr.co.il > @ 1999-03-31 23:46 ` Harvey J. Stein 1 sibling, 0 replies; 4+ messages in thread From: Harvey J. Stein @ 1999-03-31 23:46 UTC (permalink / raw) To: egcs; +Cc: hjstein 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-03-31 23:46 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-03-11 2:26 g77 plans - support for automatic, .eq. for logicals, etc? Harvey J. Stein [not found] ` < m21ziwgw5u.fsf@blinky.bfr.co.il > 1999-03-11 8:02 ` craig 1999-03-31 23:46 ` craig 1999-03-31 23:46 ` Harvey J. Stein
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).