Re: gdb and g77

Re: gdb and g77

[Andrew Vaught]

>> I get wrong answers from gdb when printing elements of a 3-dimensional
>>Fortran (g77)
>> array.  Is this a known problem, or am I missing something?  My
>>versions of g77 and gdb came with RedHat Ver 6.0 Linux.
>
>It's hard to tell without an example.  Offhand, I don't think *that*
>particular problem is know, though other g77+gdb problems are, to
>varying degrees, known (e.g. gdb 4.18 seems to not print complex
>variables correctly), and one or more of these might be what you are,
>in fact, seeing.
>
>        tq vm, (burley)

  When g77 emits debug info for arrays, the dimensions are reversed.  If
your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
but otherwise gdb will be looking at the wrong memory location for the
data.  I originally thought the problem was with gdb reversing the
dimensions, but after building gdb on an RS6K, it correctly read the
dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

         Andy

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

Sounds reasonable, though the likely cause of the problem is the gcc
back end.  The g77 front end (presumably) passes to the back end
the proper info on the array, else there'd be *huge* problems, either
in correctness or performance.  What is probably happening, then, is
that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
dwarf2out.c, etc.) aren't coping properly with multi-dimensional
arrays.

But I'm speaking on this without actually looking at any of the code,
or -g output, etc.  I'm real busy this weekend, but will try to catch
up on things like this shortly, though the fact that nobody else seems
to have found the problem already suggests that it isn't an easy problem
to spot!

        tq vm, (burley)

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

Sounds reasonable, though the likely cause of the problem is the gcc
back end.  The g77 front end (presumably) passes to the back end
the proper info on the array, else there'd be *huge* problems, either
in correctness or performance.  What is probably happening, then, is
that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
dwarf2out.c, etc.) aren't coping properly with multi-dimensional
arrays.

But I'm speaking on this without actually looking at any of the code,
or -g output, etc.  I'm real busy this weekend, but will try to catch
up on things like this shortly, though the fact that nobody else seems
to have found the problem already suggests that it isn't an easy problem
to spot!

        tq vm, (burley)

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

It seems the above analysis is wrong, but I've been getting bounces
from Andy's email address above, so I don't know whether Andy's seen
the ensuing discussion (whether he's on the egcs mailing list).

It'll be awfully sad if it turns out the Fortran mode in gdb was
*designed* wrongly, such that making it correct (which would help g77)
would break it for other compilers.

        tq vm, (burley)

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

It seems the above analysis is wrong, but I've been getting bounces
from Andy's email address above, so I don't know whether Andy's seen
the ensuing discussion (whether he's on the egcs mailing list).

It'll be awfully sad if it turns out the Fortran mode in gdb was
*designed* wrongly, such that making it correct (which would help g77)
would break it for other compilers.

        tq vm, (burley)

Re: gdb and g77

[Andrew Vaught]

>> I get wrong answers from gdb when printing elements of a 3-dimensional
>>Fortran (g77)
>> array.  Is this a known problem, or am I missing something?  My
>>versions of g77 and gdb came with RedHat Ver 6.0 Linux.
>
>It's hard to tell without an example.  Offhand, I don't think *that*
>particular problem is know, though other g77+gdb problems are, to
>varying degrees, known (e.g. gdb 4.18 seems to not print complex
>variables correctly), and one or more of these might be what you are,
>in fact, seeing.
>
>        tq vm, (burley)

  When g77 emits debug info for arrays, the dimensions are reversed.  If
your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
but otherwise gdb will be looking at the wrong memory location for the
data.  I originally thought the problem was with gdb reversing the
dimensions, but after building gdb on an RS6K, it correctly read the
dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

         Andy

Re: gdb and g77

[Tim Schmielau]

> Well, it looks like there's general doubt on this list regarding the
> statement that gdb works fine with "other" Fortran compilers.
> 
> Could whoever asserted that gdb works with "other" Fortran's please
> submit a complete example of this working, including the source code
> for a small Fortran program, the gdb session showing it working, and
> the assembler output of the "other" compiler when compiling that
> program, so we can see for ourselves just what "working" means in this
> case?

Though I didn't make that assertment, I just tested Portland Group's PGF77
on Linux/Intel against gdb, and indeed found it working.
I used the following short program:

      IMPLICIT NONE
      REAL x(5,6)
      INTEGER i,j

      DO i=1,5
         DO j=1,6
            x(i,j) = i+j*0.1
         ENDDO
      ENDDO
      WRITE(*,*) "array filled."
      END

Debug session log follows:

  > pgf77 -g arrtest.f
  > gdb a.out 
  GNU gdb 4.17.0.11 with Linux support
  Copyright 1998 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you
  are
  welcome to change it and/or distribute copies of it under certain
  conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for
  details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) b MAIN
  Breakpoint 1 at 0x8048d46: file arrtest.f, line 5.
  (gdb) r
  Starting program: /users/hoptik2/tim/test/a.out 
  
  Breakpoint 1, MAIN () at arrtest.f:5
  5             DO i=1,5
  Current language:  auto; currently fortran
  (gdb) b 10
  Breakpoint 2 at 0x8048dbb: file arrtest.f, line 10.
  (gdb) c
  Continuing.
  
  Breakpoint 2, MAIN () at arrtest.f:10
  10            WRITE(*,*) "array filled."
  (gdb) ptype x
  type = real*4 (6,5)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(1,2)
  $2 = 1.20000005
  (gdb) print x(2,1)
  $3 = 2.0999999

while the same program, compiled with g77, gives

  > g77 -g arrtest.f
  > gdb a.out
      ...
  (gdb) ptype x
  type = real*4 (5,6)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(2,1)
  $2 = 2.0999999
  (gdb) print x(1,2)
  $3 = 2.20000005

with the last being wrong. Note also the different outputs from ptype.
Output from

  > pgf77 -g -S arrtest.f

is attached.

hope this helps,
Tim Schmielau (tim@physik3.uni-rostock.de)

Re: gdb and g77

[craig]

>Though I didn't make that assertment, I just tested Portland Group's PGF77
>on Linux/Intel against gdb, and indeed found it working.

Hmm, I consider gdb to *not* be working with pgf77.  Consider:

>      REAL x(5,6)
[...]
>  > pgf77 -g arrtest.f
>  > gdb a.out 
[...]
>  (gdb) ptype x
>  type = real*4 (6,5)

That's the wrong answer!  But consider:

>  > g77 -g arrtest.f
>  > gdb a.out
[...]
>  (gdb) ptype x
>  type = real*4 (5,6)

That's the *correct* answer!

Perhaps pgf77 works around one bug in gdb and hits another, while g77
happens to do the opposite.

        tq vm, (burley)

Re: gdb and g77

[Tim Schmielau]

> Hmm, I consider gdb to *not* be working with pgf77.
> [...]
> Perhaps pgf77 works around one bug in gdb and hits another, while g77
> happens to do the opposite.

Yup, pgf77's code fails printing the whole array,

  (gdb) print x
  $17 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999,
  1.20000005) ( 2.20000005, 3.20000005, 4.19999981, 5.19999981,1.29999995,
  2.29999995) ( 3.29999995, 4.30000019, 5.30000019, 1.39999998, 2.4000001,
  3.4000001) ( 4.4000001, 5.4000001, 1.5, 2.5, 3.5, 4.5) ( 5.5,
  1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

while g77's succeeds

  (gdb) print x
  $2 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999) (
  1.20000005, 2.20000005, 3.20000005, 4.19999981, 5.19999981) (
  1.29999995, 2.29999995, 3.29999995, 4.30000019, 5.30000019) ( 
  1.39999998, 2.4000001, 3.4000001, 4.4000001, 5.4000001) ( 1.5, 2.5, 3.5,
  4.5, 5.5) ( 1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

So there really seems to be no way of teaching gdb both things.

By the way, PG's own debugger pgdbg works correctly on both pgf77's
and g77's code, so they seem to have done a fairly complete workaround (as
far as possible).
This suggests they also have investigated this point and haven't found a
better way of teaching gdb, either. 

Tim Schmielau (tim@physik3.uni-rostock.de)

Re: gdb and g77

[Tim Schmielau]

> Hmm, I consider gdb to *not* be working with pgf77.
> [...]
> Perhaps pgf77 works around one bug in gdb and hits another, while g77
> happens to do the opposite.

Yup, pgf77's code fails printing the whole array,

  (gdb) print x
  $17 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999,
  1.20000005) ( 2.20000005, 3.20000005, 4.19999981, 5.19999981,1.29999995,
  2.29999995) ( 3.29999995, 4.30000019, 5.30000019, 1.39999998, 2.4000001,
  3.4000001) ( 4.4000001, 5.4000001, 1.5, 2.5, 3.5, 4.5) ( 5.5,
  1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

while g77's succeeds

  (gdb) print x
  $2 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999) (
  1.20000005, 2.20000005, 3.20000005, 4.19999981, 5.19999981) (
  1.29999995, 2.29999995, 3.29999995, 4.30000019, 5.30000019) ( 
  1.39999998, 2.4000001, 3.4000001, 4.4000001, 5.4000001) ( 1.5, 2.5, 3.5,
  4.5, 5.5) ( 1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

So there really seems to be no way of teaching gdb both things.

By the way, PG's own debugger pgdbg works correctly on both pgf77's
and g77's code, so they seem to have done a fairly complete workaround (as
far as possible).
This suggests they also have investigated this point and haven't found a
better way of teaching gdb, either. 

Tim Schmielau (tim@physik3.uni-rostock.de)

Re: gdb and g77

[craig]

>Though I didn't make that assertment, I just tested Portland Group's PGF77
>on Linux/Intel against gdb, and indeed found it working.

Hmm, I consider gdb to *not* be working with pgf77.  Consider:

>      REAL x(5,6)
[...]
>  > pgf77 -g arrtest.f
>  > gdb a.out 
[...]
>  (gdb) ptype x
>  type = real*4 (6,5)

That's the wrong answer!  But consider:

>  > g77 -g arrtest.f
>  > gdb a.out
[...]
>  (gdb) ptype x
>  type = real*4 (5,6)

That's the *correct* answer!

Perhaps pgf77 works around one bug in gdb and hits another, while g77
happens to do the opposite.

        tq vm, (burley)

Re: gdb and g77

[Tim Schmielau]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

> Well, it looks like there's general doubt on this list regarding the
> statement that gdb works fine with "other" Fortran compilers.
> 
> Could whoever asserted that gdb works with "other" Fortran's please
> submit a complete example of this working, including the source code
> for a small Fortran program, the gdb session showing it working, and
> the assembler output of the "other" compiler when compiling that
> program, so we can see for ourselves just what "working" means in this
> case?

Though I didn't make that assertment, I just tested Portland Group's PGF77
on Linux/Intel against gdb, and indeed found it working.
I used the following short program:

      IMPLICIT NONE
      REAL x(5,6)
      INTEGER i,j

      DO i=1,5
         DO j=1,6
            x(i,j) = i+j*0.1
         ENDDO
      ENDDO
      WRITE(*,*) "array filled."
      END

Debug session log follows:

  > pgf77 -g arrtest.f
  > gdb a.out 
  GNU gdb 4.17.0.11 with Linux support
  Copyright 1998 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you
  are
  welcome to change it and/or distribute copies of it under certain
  conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for
  details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) b MAIN
  Breakpoint 1 at 0x8048d46: file arrtest.f, line 5.
  (gdb) r
  Starting program: /users/hoptik2/tim/test/a.out 
  
  Breakpoint 1, MAIN () at arrtest.f:5
  5             DO i=1,5
  Current language:  auto; currently fortran
  (gdb) b 10
  Breakpoint 2 at 0x8048dbb: file arrtest.f, line 10.
  (gdb) c
  Continuing.
  
  Breakpoint 2, MAIN () at arrtest.f:10
  10            WRITE(*,*) "array filled."
  (gdb) ptype x
  type = real*4 (6,5)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(1,2)
  $2 = 1.20000005
  (gdb) print x(2,1)
  $3 = 2.0999999

while the same program, compiled with g77, gives

  > g77 -g arrtest.f
  > gdb a.out
      ...
  (gdb) ptype x
  type = real*4 (5,6)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(2,1)
  $2 = 2.0999999
  (gdb) print x(1,2)
  $3 = 2.20000005

with the last being wrong. Note also the different outputs from ptype.
Output from

  > pgf77 -g -S arrtest.f

is attached.

hope this helps,
Tim Schmielau (tim@physik3.uni-rostock.de)

[-- Attachment #2: arrtest.s.gz --]
[-- Type: application/x-gzip, Size: 1174 bytes --]

Re: gdb and g77

[Dave Love]

>>>>> "JCB" == craig  <craig@jcb-sc.com> writes:

 JCB> But we now have info suggesting that gdb interprets debug records
 JCB> from Fortran compilers *other* than g77 (with back ends other than
 JCB> gcc, I assume) *correctly*.

The gdb support was written for a compiler with different conventions
from g77.  (I sent a copy of the paper on it a while back.)  I started
working on changes long ago but couldn't get a response from bug-gdb
about incorporating changes and no-one else seemed interested, so I
dropped it and probably no longer have the work.

 JCB> Yup.  I don't know what various debug formats should look like,
 JCB> especially in the area of multi-dimensional arrays.

I can't remember the details, but array references are quite
broken, particularly for dummy args.  They're interpreted as function
calls in Fortran mode and can crash gdb in C mode with assumed-size
arrays; e.g. in something like this, look at a and b in foo with
`print' and `whatis'.

      real a(3)
      data a /1,2,3/
      call foo(a, a)
      end
      subroutine foo(a, b)
      real a(3), b(*)
      print *, a(1), b(1)
      end

 >> We should also review the stabs & dwarf2 specs to make sure they
 >> do not specify something dumb like requiring the compiler to emit
 >> records with reversed subscripts :-)

 JCB> Indeed.  Reviewing the specs is one of the requirements for
 JCB> working on this -- which is why I haven't just dived into the
 JCB> code yet, I've got too many *other* things to review at the
 JCB> moment!

Generally there are Fortran-specific stabs and DWARFism which should
probably be emitted but aren't (for COMMON in particular).  Also
name-mangling needs treating.

For stabs, the online ( http://docs.sun.com/ ) Sun Fortran docs explain
how they deal with Fortran and one can generate sample assembler.
AFAIR, gdb works reasonably well with SunPro f77 (stabs) but doesn't
with MIPSpro (DWARF, at least now).

 JCB> So I'd very much appreciate anyone with some understanding (and
 JCB> time) helping find the culprit....

I don't know about this case, but I think the job needs doing
properly, and that's a fair amount of work.  I presume that changes
could now be got into gdb, at least.

Re: gdb and g77

[Stan Shebs]

Dave Love <d.love@dl.ac.uk> writes:

> The gdb support was written for a compiler with different conventions
> from g77.  (I sent a copy of the paper on it a while back.)  I started
> working on changes long ago but couldn't get a response from bug-gdb
> about incorporating changes and no-one else seemed interested, so I
> dropped it and probably no longer have the work.

Argh - gdb-patches would have been a better destination.  I would have
loved to get the fixes.  HP is busy working on Fortran support in
their version of GDB, so there is probably some duplicated work going
on now, sigh.

								Stan

Re: gdb and g77

[Dave Love]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

 Stan> Argh - gdb-patches would have been a better destination.  

I wasn't sending a patch and I don't know where one would learn about
that address.  It's not in MAILINGLISTS or the released gdb/README and
I'm pretty sure I DTRT according to whatever version of gdb I had at
the time.
  
 Stan> HP is busy working on Fortran support in their version of GDB,
 Stan> so there is probably some duplicated work going on now, sigh.

Not from me any more.

I hope HP stuff isn't going to interfere with potential g77 support.
HP Fortran conventions also are significantly different from g77's.

Re: gdb and g77

[Stan Shebs]

   From: Dave Love <d.love@dl.ac.uk>
   Date: 17 Jun 1999 20:22:52 +0100

   >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

    Stan> Argh - gdb-patches would have been a better destination.  

   I wasn't sending a patch and I don't know where one would learn about
   that address.  It's not in MAILINGLISTS or the released gdb/README and
   I'm pretty sure I DTRT according to whatever version of gdb I had at
   the time.

I'm not sure what "MAILINGLISTS" is supposed to be, but that's a good
point about gdb-patches not being documented well - it's in the internals
manual and on the sourceware web page, but prior to sourceware it was
only mentioned in the semi-secret ftp location, which most people didn't
know about (it seems ridiculous, now, that anybody could have thought
there was some advantage to keeping snapshots secret...).

   I hope HP stuff isn't going to interfere with potential g77 support.
   HP Fortran conventions also are significantly different from g77's.

Yes, that's why I want to stay on top of all this right now - HP is
preparing to submit Fortran support patches derived from their WDB
release, and it would be bad to have any of that collide with g77
support.

								Stan

Re: gdb and g77

[Stan Shebs]

   From: Dave Love <d.love@dl.ac.uk>
   Date: 17 Jun 1999 20:22:52 +0100

   >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

    Stan> Argh - gdb-patches would have been a better destination.  

   I wasn't sending a patch and I don't know where one would learn about
   that address.  It's not in MAILINGLISTS or the released gdb/README and
   I'm pretty sure I DTRT according to whatever version of gdb I had at
   the time.

I'm not sure what "MAILINGLISTS" is supposed to be, but that's a good
point about gdb-patches not being documented well - it's in the internals
manual and on the sourceware web page, but prior to sourceware it was
only mentioned in the semi-secret ftp location, which most people didn't
know about (it seems ridiculous, now, that anybody could have thought
there was some advantage to keeping snapshots secret...).

   I hope HP stuff isn't going to interfere with potential g77 support.
   HP Fortran conventions also are significantly different from g77's.

Yes, that's why I want to stay on top of all this right now - HP is
preparing to submit Fortran support patches derived from their WDB
release, and it would be bad to have any of that collide with g77
support.

								Stan

Re: gdb and g77

[Dave Love]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

 Stan> Argh - gdb-patches would have been a better destination.  

I wasn't sending a patch and I don't know where one would learn about
that address.  It's not in MAILINGLISTS or the released gdb/README and
I'm pretty sure I DTRT according to whatever version of gdb I had at
the time.
  
 Stan> HP is busy working on Fortran support in their version of GDB,
 Stan> so there is probably some duplicated work going on now, sigh.

Not from me any more.

I hope HP stuff isn't going to interfere with potential g77 support.
HP Fortran conventions also are significantly different from g77's.

Re: gdb and g77

[Stan Shebs]

Dave Love <d.love@dl.ac.uk> writes:

> The gdb support was written for a compiler with different conventions
> from g77.  (I sent a copy of the paper on it a while back.)  I started
> working on changes long ago but couldn't get a response from bug-gdb
> about incorporating changes and no-one else seemed interested, so I
> dropped it and probably no longer have the work.

Argh - gdb-patches would have been a better destination.  I would have
loved to get the fixes.  HP is busy working on Fortran support in
their version of GDB, so there is probably some duplicated work going
on now, sigh.

								Stan

Re: gdb and g77

[Dave Love]

>>>>> "JCB" == craig  <craig@jcb-sc.com> writes:

 JCB> But we now have info suggesting that gdb interprets debug records
 JCB> from Fortran compilers *other* than g77 (with back ends other than
 JCB> gcc, I assume) *correctly*.

The gdb support was written for a compiler with different conventions
from g77.  (I sent a copy of the paper on it a while back.)  I started
working on changes long ago but couldn't get a response from bug-gdb
about incorporating changes and no-one else seemed interested, so I
dropped it and probably no longer have the work.

 JCB> Yup.  I don't know what various debug formats should look like,
 JCB> especially in the area of multi-dimensional arrays.

I can't remember the details, but array references are quite
broken, particularly for dummy args.  They're interpreted as function
calls in Fortran mode and can crash gdb in C mode with assumed-size
arrays; e.g. in something like this, look at a and b in foo with
`print' and `whatis'.

      real a(3)
      data a /1,2,3/
      call foo(a, a)
      end
      subroutine foo(a, b)
      real a(3), b(*)
      print *, a(1), b(1)
      end

 >> We should also review the stabs & dwarf2 specs to make sure they
 >> do not specify something dumb like requiring the compiler to emit
 >> records with reversed subscripts :-)

 JCB> Indeed.  Reviewing the specs is one of the requirements for
 JCB> working on this -- which is why I haven't just dived into the
 JCB> code yet, I've got too many *other* things to review at the
 JCB> moment!

Generally there are Fortran-specific stabs and DWARFism which should
probably be emitted but aren't (for COMMON in particular).  Also
name-mangling needs treating.

For stabs, the online ( http://docs.sun.com/ ) Sun Fortran docs explain
how they deal with Fortran and one can generate sample assembler.
AFAIR, gdb works reasonably well with SunPro f77 (stabs) but doesn't
with MIPSpro (DWARF, at least now).

 JCB> So I'd very much appreciate anyone with some understanding (and
 JCB> time) helping find the culprit....

I don't know about this case, but I think the job needs doing
properly, and that's a fair amount of work.  I presume that changes
could now be got into gdb, at least.

Re: gdb and g77

[Andrew Vaught]

>>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>>but otherwise gdb will be looking at the wrong memory location for the
>>data.  I originally thought the problem was with gdb reversing the
>>dimensions, but after building gdb on an RS6K, it correctly read the
>>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.


>Sounds reasonable, though the likely cause of the problem is the gcc
>back end.  The g77 front end (presumably) passes to the back end
>the proper info on the array, else there'd be *huge* problems, either
>in correctness or performance.  What is probably happening, then, is
>that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
>dwarf2out.c, etc.) aren't coping properly with multi-dimensional
>arrays.
>
>But I'm speaking on this without actually looking at any of the code,
>or -g output, etc.  I'm real busy this weekend, but will try to catch
>up on things like this shortly, though the fact that nobody else seems
>to have found the problem already suggests that it isn't an easy problem
>to spot!
>
>        tq vm, (burley)

  As far as I could tell, the problem is in ffecom_sym_transform(), right
before and possibly after that 130-line comment.  The procedure that
generates the code for array references appears to be in another section
of code, while ffecom_sym_transform() looks like it is packaging symbols
so that the back end can write the debug information. 

  I'm not surprised that no one has complained about this.  My experience
with people who do numerical computing is that they aren't that
sophisticated when it comes to debugging-- print statements are generally
what they do.  You can blow them away by attaching to a running process
with the debugger and printing out the values of variables...

(it looks like my return address is messed up.  It is andy@xena.eas.asu.edu)

    Andy

Re: gdb and g77

[craig]

>  As far as I could tell, the problem is in ffecom_sym_transform(), right
>before and possibly after that 130-line comment.  The procedure that
>generates the code for array references appears to be in another section
>of code, while ffecom_sym_transform() looks like it is packaging symbols
>so that the back end can write the debug information. 

Right, but if ffecom_sym_transform() is giving the back end the wrong
"shape" for multi-dimensional arrays, then surely Toon, at least, would
have noticed the resulting performance degradation!

Given a Fortran declaration like

  REAL A(5,6)

the ordering of elements, in memory, is *supposed* to be:

  A(1,1)
  A(2,1)
  A(3,1)
  A(4,1)
  A(5,1)
  A(1,2)
  A(2,2)
  ...

The back end doesn't care about "row" vs. "column" ordering, however.

In the back end, an array is *always* one-dimensional, but it may be
an array of a type that is, itself, another array.  So the ordering
is whatever it's given by the front end.

(Yes, it is a "C-ish" back end, but it does have a higher-level array
facility than C itself does, insofar that C cannot represent arrays
of arrays -- instead, it represents arrays of pointers to arrays, for
example.)

So the way g77 *should* be 'splaining the above declaration to the back
end is:

  A is a VAR_DECL (or PARM_DECL)
    of type ARRAY
        (6 elements in size)
      of type ARRAY
          (5 elements in size)
        of type REAL

Then, g77 tells the back end about a reference to A(2,1) as:

  ARRAY_REF (ARRAY_REF (A, 1), 2)

So g77 handles all the "column-ordering" stuff.  The back end never
sees it.

If g77 wasn't doing this right, then it'd either be *totally* broken
(which, I think it's safe to say after years of beta-testing, is
not the case!), or both the decl *and* the reference would be set
up the same "wrong" way.

But, if both were *wrong*, then the back end would be laying out
*memory* in the "wrong" way, even though typical array code would
still work.

This "wrong" layout would not only break EQUIVALENCE/COMMON overlapping
of multi-dimensional arrays with single-dimension ones, it'd also
result in much lower performance of code that was running through
arrays element by element using the proper column-ordering convention.

*My* guess, again, without looking at any code (except insofar as I *wrote*
the g77 code, so I'm pretty sure it's correct ;-) is that the problem
is in the back end code to handle writing debugging information.

That code doesn't expect to see "an array of an array" in C.  What
it might be doing is handling it incorrectly in general.  Or, something
I've seen people do, it might be handling it *correctly* in *general*,
then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
of the subscripts, because Fortran is column-ordered".

I'd lean towards 39.999% likelihood of the former, 59.999% likelihood
of the latter, with the remaining being the likelihood of the bug
being somewhere else.

>  I'm not surprised that no one has complained about this.  My experience
>with people who do numerical computing is that they aren't that
>sophisticated when it comes to debugging-- print statements are generally
>what they do.  You can blow them away by attaching to a running process
>with the debugger and printing out the values of variables...

That's probably part of the equation: the other part being, I think
by now everybody knows g77's debuggability is pretty poor in certain
areas.

        tq vm, (burley)

Re: gdb and g77

[Jeffrey A Law]

  In message < 19990613232722.6682.qmail@deer >you write:
  >   A is a VAR_DECL (or PARM_DECL)
  >     of type ARRAY
  >         (6 elements in size)
  >       of type ARRAY
  >           (5 elements in size)
  >         of type REAL
  > 
  > Then, g77 tells the back end about a reference to A(2,1) as:
  > 
  >   ARRAY_REF (ARRAY_REF (A, 1), 2)
  > 
  > So g77 handles all the "column-ordering" stuff.  The back end never
  > sees it.
I don't think there was any question about whether or not the ordering in
memory was correct -- only questions about why g77 & gdb aren't cooperating
well.

So, let's walk through the problem.  I see two cases worth examination:

  1. gcc emits incorrect debug records.

  2. gdb interprets the debug records incorrectly.

[ ... ]

  > That code doesn't expect to see "an array of an array" in C.  What
  > it might be doing is handling it incorrectly in general.  Or, something
  > I've seen people do, it might be handling it *correctly* in *general*,
  > then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
  > of the subscripts, because Fortran is column-ordered".
I doubt it's the latter, at least in the compiler.  The code to emit
debug records is not supposed to really care about the language (and
thus shouldn't be reversing the subscripts).

A quick review of dbxout.c & dwarf2out.c leads me to believe that neither is
reversing the subscripts.  However, we should make sure by examining the
debug records created for a simple 2-d array.

Depending on what we find, we either dive back into gcc itself or we start
looking at gdb.

We should also review the stabs & dwarf2 specs to make sure they do not
specify something dumb like requiring the compiler to emit records with
reversed subscripts :-)


jeff

Re: gdb and g77

[craig]

>I don't think there was any question about whether or not the ordering in
>memory was correct -- only questions about why g77 & gdb aren't cooperating
>well.

Well, from my point of view, there *was* a question, in that, if the
bug was in the g77 front end, I couldn't see how it'd *not* be doing
something so wrong we would have detected it even without debugging
being involved.  So that suggests, to me, the problem isn't in the
front end.

>So, let's walk through the problem.  I see two cases worth examination:
>
>  1. gcc emits incorrect debug records.
>
>  2. gdb interprets the debug records incorrectly.

But we now have info suggesting that gdb interprets debug records
from Fortran compilers *other* than g77 (with back ends other than
gcc, I assume) *correctly*.

>A quick review of dbxout.c & dwarf2out.c leads me to believe that neither is
>reversing the subscripts.  However, we should make sure by examining the
>debug records created for a simple 2-d array.

Yup.  I don't know what various debug formats should look like, especially
in the area of multi-dimensional arrays.

>We should also review the stabs & dwarf2 specs to make sure they do not
>specify something dumb like requiring the compiler to emit records with
>reversed subscripts :-)

Indeed.  Reviewing the specs is one of the requirements for working on
this -- which is why I haven't just dived into the code yet, I've got
too many *other* things to review at the moment!

So I'd very much appreciate anyone with some understanding (and time)
helping find the culprit....

I wouldn't say this is *quite* a "must fix" for 2.95, since it's presumably
not a regression.  But that (flow?) bug that results in gdb letting the
first statement in a routine run before the breakpoint on that routine
name "catches", *that* I would call a "blocking bug", or nearly so.

        tq vm, (burley)

Re: gdb and g77

[craig]

>I don't think there was any question about whether or not the ordering in
>memory was correct -- only questions about why g77 & gdb aren't cooperating
>well.

Well, from my point of view, there *was* a question, in that, if the
bug was in the g77 front end, I couldn't see how it'd *not* be doing
something so wrong we would have detected it even without debugging
being involved.  So that suggests, to me, the problem isn't in the
front end.

>So, let's walk through the problem.  I see two cases worth examination:
>
>  1. gcc emits incorrect debug records.
>
>  2. gdb interprets the debug records incorrectly.

But we now have info suggesting that gdb interprets debug records
from Fortran compilers *other* than g77 (with back ends other than
gcc, I assume) *correctly*.

>A quick review of dbxout.c & dwarf2out.c leads me to believe that neither is
>reversing the subscripts.  However, we should make sure by examining the
>debug records created for a simple 2-d array.

Yup.  I don't know what various debug formats should look like, especially
in the area of multi-dimensional arrays.

>We should also review the stabs & dwarf2 specs to make sure they do not
>specify something dumb like requiring the compiler to emit records with
>reversed subscripts :-)

Indeed.  Reviewing the specs is one of the requirements for working on
this -- which is why I haven't just dived into the code yet, I've got
too many *other* things to review at the moment!

So I'd very much appreciate anyone with some understanding (and time)
helping find the culprit....

I wouldn't say this is *quite* a "must fix" for 2.95, since it's presumably
not a regression.  But that (flow?) bug that results in gdb letting the
first statement in a routine run before the breakpoint on that routine
name "catches", *that* I would call a "blocking bug", or nearly so.

        tq vm, (burley)

Re: gdb and g77

[David Edelsohn]

	Is this an issue where C specifies row-major arrays and Fortran
specifies column-major arrays?  The subscripts would appear to be reversed
if gdb did not set the language type correctly or handle the row-major
versus column-major specification.

David

Re: gdb and g77

[Jeffrey A Law]

  > 	Is this an issue where C specifies row-major arrays and Fortran
  > specifies column-major arrays?  The subscripts would appear to be reversed
  > if gdb did not set the language type correctly or handle the row-major
  > versus column-major specification.
I suspect the bug will turn out to be gdb.  But we need to verify that the
debug symbols being emitted from gcc look sane before we point a finger at
gdb  :-)

jeff

Re: gdb and g77

[Per Bothner]

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

The way it *should* work IMNSHO:
* A f77 3*2 array should be represented internally (tree nodes etc)
the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
* The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
* The internal Gdb representation of a f77 3*2 array should be the
asme as a C 2*3 array.
* When Gdb evaluates the f77 experession A(i,j) it should do the same
thing as when evaluating the C expression A[j][i].  This re-arranging
can be done by the expression parsing, or (by using a different
expression opcode) in the expression evaluator.  Because the parser
cannot distinguish a function call from an array indexing operation,
it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.

Rationale:  Logically, a f77 3*2 array is equivalent to a C 2*3 array
- it is just the order of indexes that are different.  The difference is
not one of types, but of expression syntax.  Hence the types should
be represented the same.

I worked on this some years ago, trying to clean up some code from
Motorola, but it has been a while, and may well have bit-rotten
- or been wrong in the first place.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[Jeffrey A Law]

  In message < m2yahmlidn.fsf@magnus.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > The way it *should* work IMNSHO:
  > * A f77 3*2 array should be represented internally (tree nodes etc)
  > the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
It is.

  > * The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
They are (verified by Craig & myself).

  > * The internal Gdb representation of a f77 3*2 array should be the
  > asme as a C 2*3 array.
  > * When Gdb evaluates the f77 experession A(i,j) it should do the same
  > thing as when evaluating the C expression A[j][i].  This re-arranging
  > can be done by the expression parsing, or (by using a different
  > expression opcode) in the expression evaluator.  Because the parser
  > cannot distinguish a function call from an array indexing operation,
  > it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.
These are where we'll start concentrating our efforts now that we're
fairly sure the stabs are reasonable.

jeff

Re: gdb and g77

[Jeffrey A Law]

  In message < m2yahmlidn.fsf@magnus.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > The way it *should* work IMNSHO:
  > * A f77 3*2 array should be represented internally (tree nodes etc)
  > the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
It is.

  > * The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
They are (verified by Craig & myself).

  > * The internal Gdb representation of a f77 3*2 array should be the
  > asme as a C 2*3 array.
  > * When Gdb evaluates the f77 experession A(i,j) it should do the same
  > thing as when evaluating the C expression A[j][i].  This re-arranging
  > can be done by the expression parsing, or (by using a different
  > expression opcode) in the expression evaluator.  Because the parser
  > cannot distinguish a function call from an array indexing operation,
  > it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.
These are where we'll start concentrating our efforts now that we're
fairly sure the stabs are reasonable.

jeff

Re: gdb and g77

[Per Bothner]

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

The way it *should* work IMNSHO:
* A f77 3*2 array should be represented internally (tree nodes etc)
the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
* The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
* The internal Gdb representation of a f77 3*2 array should be the
asme as a C 2*3 array.
* When Gdb evaluates the f77 experession A(i,j) it should do the same
thing as when evaluating the C expression A[j][i].  This re-arranging
can be done by the expression parsing, or (by using a different
expression opcode) in the expression evaluator.  Because the parser
cannot distinguish a function call from an array indexing operation,
it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.

Rationale:  Logically, a f77 3*2 array is equivalent to a C 2*3 array
- it is just the order of indexes that are different.  The difference is
not one of types, but of expression syntax.  Hence the types should
be represented the same.

I worked on this some years ago, trying to clean up some code from
Motorola, but it has been a while, and may well have bit-rotten
- or been wrong in the first place.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[craig]

>I suspect the bug will turn out to be gdb.  But we need to verify that the
>debug symbols being emitted from gcc look sane before we point a finger at
>gdb  :-)

Well, it looks like there's general doubt on this list regarding the
statement that gdb works fine with "other" Fortran compilers.

Could whoever asserted that gdb works with "other" Fortran's please
submit a complete example of this working, including the source code
for a small Fortran program, the gdb session showing it working, and
the assembler output of the "other" compiler when compiling that
program, so we can see for ourselves just what "working" means in this
case?

        tq vm, (burley)

Re: gdb and g77

[craig]

>I suspect the bug will turn out to be gdb.  But we need to verify that the
>debug symbols being emitted from gcc look sane before we point a finger at
>gdb  :-)

Well, it looks like there's general doubt on this list regarding the
statement that gdb works fine with "other" Fortran compilers.

Could whoever asserted that gdb works with "other" Fortran's please
submit a complete example of this working, including the source code
for a small Fortran program, the gdb session showing it working, and
the assembler output of the "other" compiler when compiling that
program, so we can see for ourselves just what "working" means in this
case?

        tq vm, (burley)

Re: gdb and g77

[Jeffrey A Law]

  > 	Is this an issue where C specifies row-major arrays and Fortran
  > specifies column-major arrays?  The subscripts would appear to be reversed
  > if gdb did not set the language type correctly or handle the row-major
  > versus column-major specification.
I suspect the bug will turn out to be gdb.  But we need to verify that the
debug symbols being emitted from gcc look sane before we point a finger at
gdb  :-)

jeff

Re: gdb and g77

[David Edelsohn]

	Is this an issue where C specifies row-major arrays and Fortran
specifies column-major arrays?  The subscripts would appear to be reversed
if gdb did not set the language type correctly or handle the row-major
versus column-major specification.

David

Re: gdb and g77

[Richard Henderson]

On Mon, Jun 14, 1999 at 12:55:31AM -0600, Jeffrey A Law wrote:
>   1. gcc emits incorrect debug records.
> 
>   2. gdb interprets the debug records incorrectly.

3.  Gdb's fortran mode prints arrays in a confusing manner.  Columns
    are printed first, since they change more frequently.  But they 
    are printed in rows.

This was the conclusion I came to doing specfp95 debugging a 
few months ago, based on the fact that printing seemed skewed,
but expression evaluation and type info (as reported by ptype)
seemed fine.

I'm really very surprised to hear a report that gdb `works ok'
with the system compiler.

Another way to test debug info in gdb is to `set lang c' and 
see if things look more reasonable.


r~

Re: gdb and g77

[Richard Henderson]

On Mon, Jun 14, 1999 at 12:55:31AM -0600, Jeffrey A Law wrote:
>   1. gcc emits incorrect debug records.
> 
>   2. gdb interprets the debug records incorrectly.

3.  Gdb's fortran mode prints arrays in a confusing manner.  Columns
    are printed first, since they change more frequently.  But they 
    are printed in rows.

This was the conclusion I came to doing specfp95 debugging a 
few months ago, based on the fact that printing seemed skewed,
but expression evaluation and type info (as reported by ptype)
seemed fine.

I'm really very surprised to hear a report that gdb `works ok'
with the system compiler.

Another way to test debug info in gdb is to `set lang c' and 
see if things look more reasonable.


r~

Re: gdb and g77

[Jeffrey A Law]

  In message < 19990613232722.6682.qmail@deer >you write:
  >   A is a VAR_DECL (or PARM_DECL)
  >     of type ARRAY
  >         (6 elements in size)
  >       of type ARRAY
  >           (5 elements in size)
  >         of type REAL
  > 
  > Then, g77 tells the back end about a reference to A(2,1) as:
  > 
  >   ARRAY_REF (ARRAY_REF (A, 1), 2)
  > 
  > So g77 handles all the "column-ordering" stuff.  The back end never
  > sees it.
I don't think there was any question about whether or not the ordering in
memory was correct -- only questions about why g77 & gdb aren't cooperating
well.

So, let's walk through the problem.  I see two cases worth examination:

  1. gcc emits incorrect debug records.

  2. gdb interprets the debug records incorrectly.

[ ... ]

  > That code doesn't expect to see "an array of an array" in C.  What
  > it might be doing is handling it incorrectly in general.  Or, something
  > I've seen people do, it might be handling it *correctly* in *general*,
  > then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
  > of the subscripts, because Fortran is column-ordered".
I doubt it's the latter, at least in the compiler.  The code to emit
debug records is not supposed to really care about the language (and
thus shouldn't be reversing the subscripts).

A quick review of dbxout.c & dwarf2out.c leads me to believe that neither is
reversing the subscripts.  However, we should make sure by examining the
debug records created for a simple 2-d array.

Depending on what we find, we either dive back into gcc itself or we start
looking at gdb.

We should also review the stabs & dwarf2 specs to make sure they do not
specify something dumb like requiring the compiler to emit records with
reversed subscripts :-)


jeff

Re: gdb and g77

[Joern Rennecke]

> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> facility than C itself does, insofar that C cannot represent arrays
> of arrays -- instead, it represents arrays of pointers to arrays, for
> example.)

Huh?  C can represent arrays of arrays just fine.

Re: gdb and g77

[craig]

>> (Yes, it is a "C-ish" back end, but it does have a higher-level array
>> facility than C itself does, insofar that C cannot represent arrays
>> of arrays -- instead, it represents arrays of pointers to arrays, for
>> example.)
>
>Huh?  C can represent arrays of arrays just fine.

That's news to me.  Care to show how?  Note I said *represent* -- not
*implement* -- as any language that provides single-dimensional arrays
can be used to *implement* multi-dimensional arrays.

So, basically, what I'm asking is, what is the C notation that denotes
the equivalent to Fortran's

  REAL A(5,6)

(except that it's row-major, of course) *including* the fact that the
storage takes up 30 units of memory *and* the fact that the same array
declaration works just fine regardless of whether A is a local variable,
in common (external) storage, or a dummy argument (the last case being
especially notable)?

Reason I ask is, in the past, C programmers have occasionally taken
to comp.lang.fortran showing how "easy" it is to cons up a set of
preprocessor macros to make C *look* like it has multi-dimensional arrays
a la Fortran.  I'm sure they'd be quite surprised to learn that C
had them all along!

        tq vm, (burley)

Re: gdb and g77

[Joern Rennecke]

> >> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> >> facility than C itself does, insofar that C cannot represent arrays
> >> of arrays -- instead, it represents arrays of pointers to arrays, for
> >> example.)
> >
> >Huh?  C can represent arrays of arrays just fine.
> 
> That's news to me.  Care to show how?  Note I said *represent* -- not
> *implement* -- as any language that provides single-dimensional arrays
> can be used to *implement* multi-dimensional arrays.
> 
> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)
> 
> (except that it's row-major, of course) *including* the fact that the
> storage takes up 30 units of memory *and* the fact that the same array
> declaration works just fine regardless of whether A is a local variable,
> in common (external) storage, or a dummy argument (the last case being
> especially notable)?

You can't have an array argument - not even a one-dimensional one.
The array decays to a pointer to its first element; if you try to pass
an array of arrays of X, you get a pointer to the first array of X.

So, the array is left at the caller site, so to speak, while the callee
has to be content with being able to manipulate all elements of the
array via the passed pointer.

(You can of course wrap an array in a struct and pass that,
 but that's cheating ;-)

Re: gdb and g77

[Joern Rennecke]

> >> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> >> facility than C itself does, insofar that C cannot represent arrays
> >> of arrays -- instead, it represents arrays of pointers to arrays, for
> >> example.)
> >
> >Huh?  C can represent arrays of arrays just fine.
> 
> That's news to me.  Care to show how?  Note I said *represent* -- not
> *implement* -- as any language that provides single-dimensional arrays
> can be used to *implement* multi-dimensional arrays.
> 
> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)
> 
> (except that it's row-major, of course) *including* the fact that the
> storage takes up 30 units of memory *and* the fact that the same array
> declaration works just fine regardless of whether A is a local variable,
> in common (external) storage, or a dummy argument (the last case being
> especially notable)?

You can't have an array argument - not even a one-dimensional one.
The array decays to a pointer to its first element; if you try to pass
an array of arrays of X, you get a pointer to the first array of X.

So, the array is left at the caller site, so to speak, while the callee
has to be content with being able to manipulate all elements of the
array via the passed pointer.

(You can of course wrap an array in a struct and pass that,
 but that's cheating ;-)

Re: gdb and g77

[Per Bothner]

craig@jcb-sc.com writes:

> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)

float A[6][5];

As Joern says:  You can't have array arguments.

And as I said:  The two declarations should generate the *same*
(or at least equivalent) debug info.  If not, I doubt you will
get much help from the Gdb people until that is fixed.

Variable-length arrays (especially variable-length array arguments)
are a differnet complication.  There is no real support for that
in stabs or Gdb, though the Motorola did implement some gross
hacks to handle some of the cases.  To handle variable-length
arrays, my incination would be to give up on stabs, and try to
design a clean solution using dwarf2.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[Per Bothner]

craig@jcb-sc.com writes:

> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)

float A[6][5];

As Joern says:  You can't have array arguments.

And as I said:  The two declarations should generate the *same*
(or at least equivalent) debug info.  If not, I doubt you will
get much help from the Gdb people until that is fixed.

Variable-length arrays (especially variable-length array arguments)
are a differnet complication.  There is no real support for that
in stabs or Gdb, though the Motorola did implement some gross
hacks to handle some of the cases.  To handle variable-length
arrays, my incination would be to give up on stabs, and try to
design a clean solution using dwarf2.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[craig]

>> (Yes, it is a "C-ish" back end, but it does have a higher-level array
>> facility than C itself does, insofar that C cannot represent arrays
>> of arrays -- instead, it represents arrays of pointers to arrays, for
>> example.)
>
>Huh?  C can represent arrays of arrays just fine.

That's news to me.  Care to show how?  Note I said *represent* -- not
*implement* -- as any language that provides single-dimensional arrays
can be used to *implement* multi-dimensional arrays.

So, basically, what I'm asking is, what is the C notation that denotes
the equivalent to Fortran's

  REAL A(5,6)

(except that it's row-major, of course) *including* the fact that the
storage takes up 30 units of memory *and* the fact that the same array
declaration works just fine regardless of whether A is a local variable,
in common (external) storage, or a dummy argument (the last case being
especially notable)?

Reason I ask is, in the past, C programmers have occasionally taken
to comp.lang.fortran showing how "easy" it is to cons up a set of
preprocessor macros to make C *look* like it has multi-dimensional arrays
a la Fortran.  I'm sure they'd be quite surprised to learn that C
had them all along!

        tq vm, (burley)

Re: gdb and g77

[Joern Rennecke]

> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> facility than C itself does, insofar that C cannot represent arrays
> of arrays -- instead, it represents arrays of pointers to arrays, for
> example.)

Huh?  C can represent arrays of arrays just fine.

Re: gdb and g77

[craig]

>  As far as I could tell, the problem is in ffecom_sym_transform(), right
>before and possibly after that 130-line comment.  The procedure that
>generates the code for array references appears to be in another section
>of code, while ffecom_sym_transform() looks like it is packaging symbols
>so that the back end can write the debug information. 

Right, but if ffecom_sym_transform() is giving the back end the wrong
"shape" for multi-dimensional arrays, then surely Toon, at least, would
have noticed the resulting performance degradation!

Given a Fortran declaration like

  REAL A(5,6)

the ordering of elements, in memory, is *supposed* to be:

  A(1,1)
  A(2,1)
  A(3,1)
  A(4,1)
  A(5,1)
  A(1,2)
  A(2,2)
  ...

The back end doesn't care about "row" vs. "column" ordering, however.

In the back end, an array is *always* one-dimensional, but it may be
an array of a type that is, itself, another array.  So the ordering
is whatever it's given by the front end.

(Yes, it is a "C-ish" back end, but it does have a higher-level array
facility than C itself does, insofar that C cannot represent arrays
of arrays -- instead, it represents arrays of pointers to arrays, for
example.)

So the way g77 *should* be 'splaining the above declaration to the back
end is:

  A is a VAR_DECL (or PARM_DECL)
    of type ARRAY
        (6 elements in size)
      of type ARRAY
          (5 elements in size)
        of type REAL

Then, g77 tells the back end about a reference to A(2,1) as:

  ARRAY_REF (ARRAY_REF (A, 1), 2)

So g77 handles all the "column-ordering" stuff.  The back end never
sees it.

If g77 wasn't doing this right, then it'd either be *totally* broken
(which, I think it's safe to say after years of beta-testing, is
not the case!), or both the decl *and* the reference would be set
up the same "wrong" way.

But, if both were *wrong*, then the back end would be laying out
*memory* in the "wrong" way, even though typical array code would
still work.

This "wrong" layout would not only break EQUIVALENCE/COMMON overlapping
of multi-dimensional arrays with single-dimension ones, it'd also
result in much lower performance of code that was running through
arrays element by element using the proper column-ordering convention.

*My* guess, again, without looking at any code (except insofar as I *wrote*
the g77 code, so I'm pretty sure it's correct ;-) is that the problem
is in the back end code to handle writing debugging information.

That code doesn't expect to see "an array of an array" in C.  What
it might be doing is handling it incorrectly in general.  Or, something
I've seen people do, it might be handling it *correctly* in *general*,
then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
of the subscripts, because Fortran is column-ordered".

I'd lean towards 39.999% likelihood of the former, 59.999% likelihood
of the latter, with the remaining being the likelihood of the bug
being somewhere else.

>  I'm not surprised that no one has complained about this.  My experience
>with people who do numerical computing is that they aren't that
>sophisticated when it comes to debugging-- print statements are generally
>what they do.  You can blow them away by attaching to a running process
>with the debugger and printing out the values of variables...

That's probably part of the equation: the other part being, I think
by now everybody knows g77's debuggability is pretty poor in certain
areas.

        tq vm, (burley)

Re: gdb and g77

[Andrew Vaught]

>>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>>but otherwise gdb will be looking at the wrong memory location for the
>>data.  I originally thought the problem was with gdb reversing the
>>dimensions, but after building gdb on an RS6K, it correctly read the
>>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.


>Sounds reasonable, though the likely cause of the problem is the gcc
>back end.  The g77 front end (presumably) passes to the back end
>the proper info on the array, else there'd be *huge* problems, either
>in correctness or performance.  What is probably happening, then, is
>that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
>dwarf2out.c, etc.) aren't coping properly with multi-dimensional
>arrays.
>
>But I'm speaking on this without actually looking at any of the code,
>or -g output, etc.  I'm real busy this weekend, but will try to catch
>up on things like this shortly, though the fact that nobody else seems
>to have found the problem already suggests that it isn't an easy problem
>to spot!
>
>        tq vm, (burley)

  As far as I could tell, the problem is in ffecom_sym_transform(), right
before and possibly after that 130-line comment.  The procedure that
generates the code for array references appears to be in another section
of code, while ffecom_sym_transform() looks like it is packaging symbols
so that the back end can write the debug information. 

  I'm not surprised that no one has complained about this.  My experience
with people who do numerical computing is that they aren't that
sophisticated when it comes to debugging-- print statements are generally
what they do.  You can blow them away by attaching to a running process
with the debugger and printing out the values of variables...

(it looks like my return address is messed up.  It is andy@xena.eas.asu.edu)

    Andy

gdb and g77

[Peter Hirsch]

 I get wrong answers from gdb when printing elements of a 3-dimensional
Fortran (g77)
 array.  Is this a known problem, or am I missing something?  My
versions of g77 and gdb came with RedHat Ver 6.0 Linux.

Re: gdb and g77

[craig]

> I get wrong answers from gdb when printing elements of a 3-dimensional
>Fortran (g77)
> array.  Is this a known problem, or am I missing something?  My
>versions of g77 and gdb came with RedHat Ver 6.0 Linux.

It's hard to tell without an example.  Offhand, I don't think *that*
particular problem is know, though other g77+gdb problems are, to
varying degrees, known (e.g. gdb 4.18 seems to not print complex
variables correctly), and one or more of these might be what you are,
in fact, seeing.

        tq vm, (burley)

Re: gdb and g77

[craig]

> I get wrong answers from gdb when printing elements of a 3-dimensional
>Fortran (g77)
> array.  Is this a known problem, or am I missing something?  My
>versions of g77 and gdb came with RedHat Ver 6.0 Linux.

It's hard to tell without an example.  Offhand, I don't think *that*
particular problem is know, though other g77+gdb problems are, to
varying degrees, known (e.g. gdb 4.18 seems to not print complex
variables correctly), and one or more of these might be what you are,
in fact, seeing.

        tq vm, (burley)

gdb and g77

[Peter Hirsch]

 I get wrong answers from gdb when printing elements of a 3-dimensional
Fortran (g77)
 array.  Is this a known problem, or am I missing something?  My
versions of g77 and gdb came with RedHat Ver 6.0 Linux.