This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g77 assumed array patch [was: fortran regression]
- To: egcs at cygnus dot com
- Subject: Re: g77 assumed array patch [was: fortran regression]
- From: Dave Love <d dot love at dl dot ac dot uk>
- Date: 19 Dec 1997 17:07:41 +0000
- References: <24592.882516126@hurl.cygnus.com>
>>>>> "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 :-(.