Re: g77 assumed array patch [was: fortran regression]

[Dave Love <d.love@dl.ac.uk>]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

 Jeffrey> I do worry a little about the "hope debuggers can deal"
 Jeffrey> issues with an unspecified high bound.  Maybe we should set
 Jeffrey> an artificial one if some debuggers don't handle unspecified
 Jeffrey> bounds correctly.

Well, gdb definitely still can't cope with the debugging info
produced, though the bound now appears as -1 rather than 2147483647.

FWIW, this with g77 -g using the rth patch:
      real a(10)
      do i=1,10
        a(i)=i
      end do
      call foo(a)
      end
      subroutine foo(a)
      real a(*)
      print *, a(1)
      end

produces:

Breakpoint 2, foo_ (a=0xbffff590) at /tmp/x.f:9
9             print *, a(1)
Current language:  auto; currently fortran
(gdb) whatis a
type = PTR TO -> ( real*4 (-1))
(gdb) set lang c
Warning: the current language does not match this frame.
(gdb) p a[1]
Segmentation fault
$

If I compile the same thing with (an old) sunpro f77 on sunos4
(stabs), gdb will show me something sensible (which I didn't expect :-)):

Breakpoint 2, foo (a=()) at x.f:9
9             print *, a(1)
(gdb) whatis a
type = real*4 (0:-1)
(gdb) p a
$1 = ()
(gdb) p a(1)
$2 = 1
(gdb) 

I don't remember what gdb is doing here (or expecting) in the the g77
case, though I did follow it once.  gdb's fortran conventions are
those of some motorola compiler AFAIK.  [You can't use `p a(1)' with
lang fortran on the g77 output because it's interpreted as a function
call.]

I'll be happy to help sort it out if anyone has good ideas how to
proceed.  There are some other problems with g77 debugging info which
probably need to be sorted out in the backend; bits of the fortran
frontend currently use symbols like
IF_SOMEONE_GETS_DEBUGGING_SUPPORT_WORKING :-(.