g77 compiles directly to assembler code like
instead of translating to an intermediate language (C) as does
support for debugging can be better for
g77 might be somewhat more "native" in terms of
debugging support than
gcc, there still are a lot
of things "not quite right".
Many of the important ones should be resolved in the near future.
g77 doesn't have to worry about reserved names
FOR = WHILE,
f2c must necessarily
translate this to something other than
for = while;, because C reserves those words.
g77 does still uses things like an extra level of indirection
ENTRY-laden procedures--in this case, because the back end doesn't
yet support multiple entry points.
Another example is that, given
COMMON A, B EQUIVALENCE (B, C)
g77 user should be able to access the variables directly, by name,
without having to traverse C-like structures and unions, while
is unlikely to ever offer this ability (due to limitations in the
However, due to apparent bugs in the back end,
g77 currently doesn't
take advantage of this facility at all--it doesn't emit any debugging
other than information
on the array of
char it creates (and, in the case
EQUIVALENCE, names) for each such area.
Yet another example is arrays.
g77 represents them to the debugger
using the same "dimensionality" as in the source code, while
must necessarily convert them all to one-dimensional arrays to fit
into the confines of the C language.
However, the level of support
offered by debuggers for interactive Fortran-style access to arrays
as compiled by
g77 can vary widely.
In some cases, it can actually
be an advantage that
f2c converts everything to widely supported
g77 could do many of the things
to get things working at least as well as
the developers prefer making
g77 work the
way they think it is supposed to, and finding help improving the
other products (the back end of
gdb; and so on)
to get things working properly.