Conference turris::fortran

1231.0. "Symbol table bug for common blocks in modules used by contained routines" by TLE::LUCIA (http://asaab.zko.dec.com/~lucia/biography.html) Wed Mar 19 1997 09:53

A customer (ESCA) reported a bug against ladebug where ladebug can't digest the
symbol table for his program.  I believe the symbol table is in error. 
Essentially, there is a common block inside a module which is used by a
contained routine.  This scenario causes the common block contents to be
duplicated inside the block definition.  Ladebug gets made when it sees two
symbols at the same address in the same scope, because it can't tell them apart.
This is really only a problem for common blocks since ladebug must compute the
addresses since ld does not.

Here is the (erroneous) symbol table.  Note that symbol 4 is a repeat of 2, 5 is
a repeat of 3.  In the customer example, the block has 149 (times six!) elements.

FILE 25. mergable, new, Fortran:

Binary of auxes:
  0. 0x00000030   0x00001fff   0x00000001   0x00000020   0x00000020   


Local Symbols:
from file foo_   Printf aux if present
  0. ( 0)(   0) foo_       File       Text       symref 8
  1. ( 1)( 0x8) foo_       Block      Common     symref 7
  2. ( 2)(   0) $m$i_      Member     Info       [ 3] 32-bit long
  3. ( 2)(0x20) $m$j_      Member     Info       [ 3] 32-bit long
  4. ( 2)(   0) $m$i_      Member     Info       [ 4] 32-bit long
  5. ( 2)(0x20) $m$j_      Member     Info       [ 4] 32-bit long
  6. ( 1)(   0)            End        Common     symref 1
  7. ( 0)(   0) foo_       End        Text       symref 0

File indirect table:
  0. 24
  1. 25


Sources are below.

Thanks,
Tim


==========Makefile==========
RM      = rm -f

all:    main

mod.o:  mod.f90
        f90 -g -c mod.f90

sub.o:  mod.o sub.f90
        f90 -g -c sub.f90

main.o: main.f90 mod.o
        f90 -g -c main.f90

main:   main.o mod.o sub.o
        f90 -g -o main main.o mod.o sub.o

clean:
        $(RM) mod.o main.o sub.o main m.mod
==========main.f90==========
      program tim
      use m
      i = 1
      call sub()

      print *, i, j
      end program
==========mod.f90==========
      module m
      common /foo/ I,J
      end module m
==========sub.f90==========
      subroutine sub
      use m
      i = 2
      call sub1()
      contains
      subroutine sub1
      use m
      i = 3
      end subroutine sub1

      end

    
    
    FYI,
    
    This problem does not reproduce with the BL36 based F90 GEM project
    compiler:
    
    Binary of auxes:
      0. 0x000000fc   0xfece8cf6   0x00000030   0x00001001   0x00000020
    
    
    Local Symbols:
    from file foo_   Printf aux if present
      0. ( 0)(   0) foo_       File       Text       symref 6
      1. ( 1)( 0x8) foo_       Block      Common     symref 5
      2. ( 2)(   0) m$i_       Member     Info       [ 4] 32-bit long
      3. ( 2)(0x20) m$j_       Member     Info       [ 4] 32-bit long
      4. ( 1)(   0)            End        Common     symref 1
      5. ( 0)(   0) foo_       End        Text       symref 0
    
    
    Bob
    

    Based on experiments performed on Eludom, I believe this is fixed
    in the latest BL33 compiler.
    
    Keith

What version should I tell this customer?  I don't supposed he can order
"BL33"...

    Well, V4.1 is BL33, but that doesn't guarantee that the bug is absent
    there.  Someone will have to try it on V4.1.
    
    				Steve

    Appears *NOT* to be fixed in Fortran 90 V1.1.
    However, it's fixed in the current development compiler.
    
    Keith

We're planning to do an ECO for DF v4.1 in April-1997 so that kit {when
available} will contain the fix.  That kit will be announced in the low notes
here.

/Stan