How to see labels in common block

[Toon Moene]

Andy,

I wrote:

> Andy Vaught wrote:

>> [ Patch to show common block items in debugger ]

> Well, I haven't seen your patch before (otherwise I'd certainly have
> given it a try - support of debug information for COMMON block items is
> on the top-3 list of desirable improvements of g77 ...)
> 
> I bootstrapped the CVS trunk with your patch (which applied with a lot
> of "offset" whining) and passed the testsuite with no regressions.
> However, the g77 testsuite doesn't seem to use the -g option (according
> to the g77.log file) so I also compiled all source files with -g -c
> -O[3] without adverse effects.

Unfortunately, this just means our (Fortran) testsuite is not
comprehensive enough.  I tested the following with a gcc-2.95.2
distribution updated with your patch.

[toon@moene g77-bugs]$ cat equivalence.f
      subroutine aap(k)
      equivalence (i,r)
      i = k
      print*,r
      end

[toon@moene g77-bugs]$ g77 -g -c -O equiv*.f
g77: Internal compiler error: program f771 got fatal signal 11

[toon@moene g77-bugs]$ gdb
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/f771 core
GNU gdb 19990816
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"...
Core was generated by
`/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/f771 equivalence.f
-quiet -dump'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x80da74b in instantiate_decl (x=0x8271244, size=4, valid_only=1) at
../../egcs/gcc/function.c:3615
3615      if (CONSTANT_P (addr)
(gdb) list
3610    
3611      if (x == 0 || GET_CODE (x) != MEM)
3612        return;
3613    
3614      addr = XEXP (x, 0);
3615      if (CONSTANT_P (addr)
3616          || (GET_CODE (addr) == ADDRESSOF && GET_CODE (XEXP (addr,
0)) == REG)
3617          || (GET_CODE (addr) == REG
3618              && (REGNO (addr) < FIRST_VIRTUAL_REGISTER
3619                  || REGNO (addr) > LAST_VIRTUAL_REGISTER)))
(gdb) p (addr->fld[0].rtx)->code
Cannot access memory at address 0x504c438b.

[ The print statement is the equivalent of GET_CODE (XEXP (addr, 0)) -
  note how the debug info is off one line: 3615 should be 3616 ]

This is basically the most dumbed down version of a problem I saw in
several of our NWP routines.

Apparently it is important that one item in the equivalence pair is
assigned from a dummy argument.  Without optimisation, there's no
problem.  Might it be that optimisation tries to do something clever
with k, messing up the equivalence (you can't equivalence a variable to
an dummy argument in Fortran) ?

Perhaps you (or someone else) can shed some light on this ?

Thanks in advance,

--  
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://gcc.gnu.org/onlinedocs/g77_news.html