Re: g77/gdb and complex numbers.

Re: g77/gdb and complex numbers.

[Toon Moene]

Jose L Gomez Dans wrote:

>         Yesterday, I posted to comp.lang.fortran a query about how the
> g77/gdb duo treat complex numbers. Basically, I cannot inspect complex
> number arrays (or single complex variables). 

Craig already answered this one.  Now for the easy part:

> Also, in this sort of test
> programs, I cannot redirect my output to the console. print* -statements
> print fine on gdb, but when executed from the pront, I just get a clean
> prompt again. This is the test program:

...

>        So, I compile the above program with g77 -g -Wall -o test test.f

...

>         Also, why with this short program, and running it in the console, I
> get no output whatsoever?

I'm sorry to say that this is a textbook example - it's from the g77
manual ("Bugs not in GNU Fortran"):

You named the executable `test'.  Don't do that.  It will run better by
any other name.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html
>From todi@scl.ameslab.gov Tue Jul 06 13:02:00 1999
From: Rajat Todi <todi@scl.ameslab.gov>
To: Mumit Khan <khan@xraylith.wisc.EDU>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Bug Report for EGCS 2.91.66 
Date: Tue, 06 Jul 1999 13:02:00 -0000
Message-id: <Pine.SGI.3.95.990706150140.851D-100000@arachne.scl.ameslab.gov>
References: <199907060023.TAA28164@mercury.xraylith.wisc.edu>
X-SW-Source: 1999-07/msg00218.html
Content-length: 1316

Hi Khan,

Thanks for your reply. 

With Regards,

Rajat Todi


On Mon, 5 Jul 1999, Mumit Khan wrote:

> Date: Mon, 05 Jul 1999 19:23:43 -0500
> From: Mumit Khan <khan@xraylith.wisc.EDU>
> To: Rajat Todi <todi@scl.ameslab.gov>
> Cc: egcs-bugs@egcs.cygnus.com
> Subject: Re: Bug Report for EGCS 2.91.66 
> 
> Rajat Todi <todi@scl.ameslab.gov> writes:
> > Hi,
> > 
> > Here is the bug which I found in the latest version of gcc version
> > egcs 2.91.66. 
> > 
> > Here is the extracted program. I have taken out problem part out
> > of the bigger code (PABLO from UIUC research).
> > 
> > // main.C
> > #
> > #
> > #include <stream.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <values.h>
> > 
> > 
> > main( int argc, char **argv ) {
> > 
> > 	enum Status       { INVALID, VALID };
> > 	Status 		     inputFileStatus;
> > 
> > 	int pktCount = 0;
> > 
> > 	while(1) {
> > 
> > 		if ( ( ++pktCount % 1000 ) == 0 ) {
> > 			cerr << pktCount << "... ";
> > 			cerr.flush();
> > 		}
> > 	}
> > 
> > }
> > 
> > // end of main.C
> 
> [ egcs-1.1.2 ICE with -O  ]
> 
> Yes, I've run into something very similar with egcs-1.1.x; good
> news is that gcc-2.95 seems to have fixed the problem. 
> 
> Interestingly enough, the bug only appears in egcs-1.1.x with -Ox, 
> x = {1,2}.
> 
> Regards,
> Mumit
> 
> 
> 

Re: g77/gdb and complex numbers.

[craig]

[bug-gdb: In case this hasn't already been reported, gdb 4.18 doesn't
print Fortran complex numbers correctly, as shown below.  Another rare
case of a g77/gdb problem that seems to be a gdb problem (most of them
are g77 problems, or at least mostly so).]

>	Yesterday, I posted to comp.lang.fortran a query about how the
>g77/gdb duo treat complex numbers. Basically, I cannot inspect complex
>number arrays (or single complex variables). Also, in this sort of test
>programs, I cannot redirect my output to the console. print* -statements
>print fine on gdb, but when executed from the pront, I just get a clean
>prompt again. This is the test program:

>(gdb) p carr
>$1 = (Invalid F77 type code 3 in symbol table.
>(gdb) p carr(1)
>$2 = Invalid F77 type code 3 in symbol table.

I believe those diagnostics are due to the g77 option `-femulate-complex'
being the default in EGCS versions 1.0 and 1.1.

In the soon-to-be-released EGCS 1.2, which has been renamed GCC 2.95,
`-fno-emulate-complex' is now the default, as we believe the remaining
back-end bugs affecting "native" complex types have been fixed.

The good news is, this should cause gdb to recognize COMPLEX numbers.

The bad news is, it seems gdb doesn't print them correctly -- it prints
the real value twice, instead of the real value then the imaginary value.

Enclosed below is a gdb session that shows this.

>	Also, why with this short program, and running it in the console, I
>get no output whatsoever?

I don't know what "running it in the console" means in this context --
it works fine for me, running it from my shell (bash), on my Redhat Linux
5.2 system.

        tq vm, (burley)


Current directory is ~/gnu/play/
GNU gdb 4.18
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) break 18
Breakpoint 1 at 0x804c074: file ../../../../egcs-19990629/libf2c/libF77/main.c, line 18.
(gdb) delete 1
(gdb) break complex.f:18
Breakpoint 2 at 0x8048d50: file complex.f, line 18.
(gdb) r
Starting program: /home3/craig/gnu/play/a.out 

Breakpoint 2, MAIN__ () at complex.f:28
Current language:  auto; currently fortran
(gdb) c
Continuing.
 Press a key

Program received signal SIGINT, Interrupt.
0x400926f4 in read () from /lib/libc.so.6
(gdb) b complex.f:39
Breakpoint 3 at 0x8048eff: file complex.f, line 39.
(gdb) c
Continuing.
k
 Values of carr
 Complex Value   Real Part   Imaginary Part
0.0000 9.0000   .0000E+00       0.9000E+01
1.0000 8.0000   .1000E+01       0.8000E+01
2.0000 7.0000   .2000E+01       0.7000E+01
3.0000 6.0000   .3000E+01       0.6000E+01
4.0000 5.0000   .4000E+01       0.5000E+01
5.0000 4.0000   .5000E+01       0.4000E+01
6.0000 3.0000   .6000E+01       0.3000E+01
7.0000 2.0000   .7000E+01       0.2000E+01
8.0000 1.0000   .8000E+01       0.1000E+01
9.0000 0.0000   .9000E+01       0.0000E+00

Breakpoint 3, MAIN__ () at complex.f:39
(gdb) p carr
$1 = ((0,0), (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7), (8,8), (9,9))
(gdb) p drpart
$2 = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
(gdb) p dimag
$3 = (9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
(gdb) set lang c
Warning: the current language does not match this frame.
(gdb) p carr
$4 = {Invalid C/C++ type code 20 in symbol table.
(gdb) set lang default
Unknown language `default'.
(gdb) set lang
The currently understood settings are:

local or auto    Automatic setting based on source file
c                Use the C language
c++              Use the C++ language
asm              Use the Asm language
chill            Use the Chill language
fortran          Use the Fortran language
java             Use the Java language
modula-2         Use the Modula-2 language
scheme           Use the Scheme language
(gdb) set lang auto
(gdb) p carr
$5 = ((0,0), (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7), (8,8), (9,9))
(gdb) p carr(1)
$6 = (0,0)
(gdb) p imag(carr(1))
No symbol "imag" in current context.
(gdb) p aimag(carr(1))
No symbol "aimag" in current context.
(gdb) set lang c
(gdb) p &carr[0]
$7 = (complex *) 0xbffffc58
(gdb) p *$
$8 = Invalid C/C++ type code 20 in symbol table.
(gdb) p (float *) $7
$9 = (float *) 0xbffffc58
(gdb) p $9[0]
$10 = 0
(gdb) p $9[1]
$11 = 9
(gdb) p $9[2]
$12 = 1
(gdb) p $9[3]
$13 = 8
(gdb) p $9[4]
$14 = 2
(gdb) p $9[5]
$15 = 7
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Debugger finished

g77/gdb and complex numbers.

[Jose L Gomez Dans]

Hi!
	Yesterday, I posted to comp.lang.fortran a query about how the
g77/gdb duo treat complex numbers. Basically, I cannot inspect complex
number arrays (or single complex variables). Also, in this sort of test
programs, I cannot redirect my output to the console. print* -statements
print fine on gdb, but when executed from the pront, I just get a clean
prompt again. This is the test program:

***************************************************************
      PROGRAM TEST

      complex carr(10)
      character key
      dimension drpart(10), dimag(10)
      real pi
      pi=3.141592
      print*,'Press a key'
      read*,key
      print*,'Values of carr'
      print*,'Complex Value   Real Part   Imaginary Part'
      do i=1,10
        carr(i)=cmplx(real(i-1),real(10-i))
        drpart(i)=real(carr(i))
        dimag(i)=aimag(carr(i))
        print 999, carr(i),drpart(i),dimag(i)
      end do
 999  format(F6.4,1x,F6.4,3x,E9.4,3x,E14.4)
      STOP
      END
******************************************************

and this is the output from g77 -v...
#############################################################################
g77 version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (from FSF-g77 version 0.5.24-19981002)
Driving: g77 -v -c -xf77-version /dev/null -xnone
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)
 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D_LANGUAGE_FORTRAN -traditional -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di486 -D__i486 -D__i486__ /dev/null /dev/null
GNU CPP version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/f771 -fnull-version -quiet -dumpbase g77-version.f -version -fversion -o /tmp/cc8B9Bhm.s /dev/null
GNU F77 version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (i486-linux) compiled by GNU C version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release).
GNU Fortran Front End version 0.5.24-19981002
 as -V -Qy -o /tmp/ccw7rYpB.o /tmp/cc8B9Bhm.s
GNU assembler version 2.9.1 (i486-linux), using BFD version 2.9.1.0.22
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/cci1kmdR /tmp/ccw7rYpB.o /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/crtbegin.o -L/usr/lib/gcc-lib/i486-linux/egcs-2.91.66 -lg2c -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/crtend.o /usr/lib/crtn.o
 /tmp/cci1kmdR
__G77_LIBF77_VERSION__: 0.5.24
@(#)LIBF77 VERSION 19970919
__G77_LIBI77_VERSION__: 0.5.24-19981021
@(#) LIBI77 VERSION pjw,dmg-mods 19980617
__G77_LIBU77_VERSION__: 0.5.24-19990305
@(#) LIBU77 VERSION 19980709

#############################################################################

       So, I compile the above program with g77 -g -Wall -o test test.f, and
then run gdb test. This is how the session looks like

GNU gdb 4.18
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) break 18
Breakpoint 1 at 0x8049010: file test.f, line 18.
(gdb) run
Starting program: /home/jgomez/test
 Press a key
K
 Values of carr
 Complex Value   Real Part   Imaginary Part
0.0000 9.0000   .0000E+00       0.9000E+01
1.0000 8.0000   .1000E+01       0.8000E+01
2.0000 7.0000   .2000E+01       0.7000E+01
3.0000 6.0000   .3000E+01       0.6000E+01
4.0000 5.0000   .4000E+01       0.5000E+01
5.0000 4.0000   .5000E+01       0.4000E+01
6.0000 3.0000   .6000E+01       0.3000E+01
7.0000 2.0000   .7000E+01       0.2000E+01
8.0000 1.0000   .8000E+01       0.1000E+01
9.0000 0.0000   .9000E+01       0.0000E+00

Breakpoint 1, MAIN__ () at test.f:19
19            stop
Current language:  auto; currently fortran
(gdb) p carr
$1 = (Invalid F77 type code 3 in symbol table.
(gdb) p carr(1)
$2 = Invalid F77 type code 3 in symbol table.
(gdb) p drpart
$3 = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
(gdb) p dimag
$4 = (9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
(gdb) p key
$5 = (75 'K')

	As you can see, all variables seem to be recognised (characters and
doubles, integers show up nicely as well, though this isn't shown). Complex
data seems to be the problem. Any ideas on this.

	Also, why with this short program, and running it in the console, I
get no output whatsoever?

	Thanks in advance,
	Jose
	

-- 
Jose L Gomez Dans			PhD student
					Radar & Communications Group
					Department of Electronic Engineering
					University of Sheffield UK