Re: g77 bug with ENTRY statement

["Steven G. Kargl" <kargl at troutmask dot apl dot washington dot edu>]

Once upon a time, craig@jcb-sc.com said:
> >      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.

How does the a GOTO help when you can do?

      subroutine a(x,y,z)
      z=x+y
      goto 1
      entry b(i)
      i=int(z)
1     return
      end

      program main
      call b(i)
      write(*,*) i
      end

If I understand F77, then z is a *dummy* argument to 
subroutine a(), and it is not guaranteed by the Fortran 77
standard to be available for entry b(). 

> 
> >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.

g77, f2c+gcc, and the Portland Group's pgf77 (version 1.7 for linux)
miss this problem.  All of the images produced by these compiler give
a segmentation fault.  Compaq's (nee Digital's) compiler issues a
warning that z is an undefined variable in entry b(), but compiles the
code anyway.  This original code also makes it through ftnchek without
a warning.

I should note that this isn't my code, but some one reported the problem
in a bug report to FreeBSD (http://www.freebsd.org).  Upon looking at
the code, I think the original author wants: 

      subroutine a(x,y,z)
      save zz
      data zz /0./
      z=x+y
      zz = z
      return
      entry b(i)
      i=int(zz)
      return
      end

> (I think "Debugging and Interfacing" in the g77 docs explains how g77
> translates ENTRY, if you want to learn more about the issues.)
 
I just read this section.  Ouch, my head hurts!   Seems you tried to
cover all the bases.




-- 
Steve