Re: Problems with g77 (GNU and egcs) and assigned GOTO

[craig at jcb-sc dot com]

[Courtesy copies to g77 bug-reporting addresses, so people there can
keep up.]

First, my new email address is <craig@jcb-sc.com>, though I do
occasionally pick up email at <burley@gnu.org>.

Second, g77 problems (bug reports, etc.) are best reported to either
<fortran@gnu.org> (for the FSF version of g77) or <egcs-bugs@egcs.cygnus.com>
(for the egcs version of g77).  The "Reporting Bugs" section of the
g77 manual should have explained this.  I'll forward your bug reports
to both addresses, since they should be seen by both audiences (pertaining
as they do to both variants of g77).  Also, egcs-bugs is archived,
while the gnu.org address has some g77/Fortran experts that might not
be on egcs-bugs.

Third, egcs developers, including myself, have been working to make
information on g77, including late-breaking news and known bugs,
more up-to-date and available.  Unfortunately, I haven't been keeping
<ftp://alpha.gnu.org/g77.plan> up-to-date since changing ISPs, but
hope to get back to that soon.  In the meantime, you might want to
take a look at:

  <http://egcs.cygnus.com/onlinedocs/g77_toc.html>

It has the whole g77 manual (but not in one big HTML read, thank
goodness).  Check out "News" and "Known Causes of Trouble...",
including either "Actual Bugs" or "Known Bugs" (I recently changed
the section title).

You might find bugs relating to ASSIGN fixed in some recent versions
of g77.  (I know there have been, but can't recall which versions
offhand.)

>(gdb) n
>398           ASSIGN 20047 TO NPR007
>(gdb) n
>399           GO TO 30007
>(gdb) p npr007
>$6 = 1

This is not surprising.  See "Assigned Statement Labels" in the docs
for more information.

>(gdb) n
>359           GO TO NPR007, (20045,20046,20047)
>(gdb) n
>Cannot insert breakpoint 0:
>Temporarily disabling shared library breakpoints:
>0 

Hmm, that looks like some kind of reachability bug in g77+gdb.

I'm not real strong on how gdb in particular does its work, but
source-debugger technologies generally rely on "reachability"
info to perform what gdb calls "next" and "step" reasonably fast.

"reachability" info shows where a source statement, or block of
source statements, might potential "go" to.  The debugger consults
this info to set temporary, internal breakpoints on all the
reachable places, then performs an internal "continue" (gdb's
terminology again) to implement "next" or "step".

So it might be that the back end isn't providing the proper
reachability info in the -g output, or gdb isn't interpreting
it properly, or something like that.

It might be worthwhile to report the above as a bug in gdb's
behavior.  Though the gdb people (dunno the bug-reporting address,
check gdb's docs) might determine it's a bug in gcc's behavior,
they'll likely be much more specific in pointing out the culprit.

But I could be wrong about this whole reachability thing vis-a-vis
gdb.  I haven't explored the internals of gdb yet.  Other debuggers
I've known include some that have used it, and some that haven't
(implementing "next"/"step" as a bunch of assembly-level single
steps, IIRC).

>Curiously, in each of these failures, there have been a great many
>successful uses of assigned goto before the failure.

Of the very same ASSIGN/GOTO combinations, i.e. the exact same
statements in the source?  That'd suggest some kind of register-tracking
bug in the back end, moreso than a g77 front-end bug.  But there
have been, in the past, g77 front-end bugs in this area, which is
why I think you should investigate that first.

>So, have you folks ever had problem reports with g77 due to assigned
>gotos that might uncover a solution to this problem?

Yep...review the news/bugs info to see some of the results.  If you
really want to have fun, explore gcc/f/ChangeLog in the pertinent
g77, to see all the code changes.  :)

>Right now, I'm stalled in my porting attempts, and cannot proceed
>until I get a working Fortran 77 compiler on GNU/Linux, and as far as
>I know, g77 is the only one available.

No, there's also f2c+gcc, sometimes systems offer a "f77" or "fort77"
script to invoke them for you.  Worth a try, though I forget offhand
how f2c handles ASSIGN/GOTO (perhaps using ordinals and computed
GOTO, which I've done in the past for a Fortran->mini-Fortran
transformer).

>I don't have g77 installed on any of my other UNIX architectures, but
>I'm going to do a build on Sun Solaris 2.6 shortly of the egcs-1.1.1
>release, since that appears to be newest.  If the problem goes away
>with the SFTRAN3 processor, and PLOT79 builds and tests successfully,
>then the finger would be pointed at the Intel x86 code generator in
>the g77/gcc backend.  However, if the problem persists, then it is
>more likely in intermediate code.

Ultimately, the problem needs to be tracked down to specifically
what (line of) Fortran code is incorrectly transformed by g77,
and we usually expect users to do that.  But, if you can come up
with a simple test case that clearly shows the misbehavior, we can
sometimes deal with that.  (Again, "Reporting Bugs" explains much
of this.)

>Because of the large number of radically different architectures and
>operating systems that PLOT79 has been installed on, I very much doubt
>that the problem lies in its Fortran code, but much more likely, in
>the Fortran compiler.

A generally reasonable assumption, but keep in mind that g77 is the
first-ever *portable* source-available native optimizing compiler for
Fortran, and this causes it to perform transformations on the source
code unlike most (or all) widely-used Fortran compilers that came
before it.  As a result, it has often been the first compiler to find
bugs in long-deployed Fortran code that had worked with many other
vendor compilers.  The "Assigned Statement Labels" node in the docs
describes just one example of the sort of thing g77 probably does
differently than most every other compiler out there.  I recommend
you read through the whole "Collected Fortran Wisdom" and "Debugging
and Interfacing" chapters to get a more complete picture of how
much g77 might differ from your expectations (and those of a huge
number of experienced Fortran programmers)!

Also, keep in mind g77 is still officially in beta test, along with
its documentation.  Not that we happily live with bugs or anything,
but there's a lot that has yet to be documented, I'm afraid....

        tq vm, (burley)