Re: g77 bug with ENTRY statement

[craig at jcb-sc dot com]

>      i=int(z)              ! z is no longer in scope.

Yes it is.  Judicious use of GOTOs would make it perfectly okay for
code literally following the ENTRY in the source to refer to Z.  It
is only because the code flows from that Z-less ENTRY into a reference
to Z that an undefined behavior is triggered.

>g77 should issue a warning that z is a dummy argument in 
>subroutine a() and that it is undefined at entry b().

That'd be great.  Ideally the gcc back end would notice this, but the
way the front end tells it about what's going on basically prevents
it.  This is probably still due to the back end not offering powerful-
enough constructs, though maybe no longer, and the front end is out of
date.  (Essentially it is a flow-control-related problem to detect
this in the general case a la gcc and other uninitialized-variable
warnings.)

Another approach is to write a g77-front-end-specific pass to detect
problems like this.  I don't recommend that, since it basically duplicates
code already in the gcc back end, applied to g77's internal structures,
which need to be redesigned anyway.

(I think "Debugging and Interfacing" in the g77 docs explains how g77
translates ENTRY, if you want to learn more about the issues.)

        tq vm, (burley)