When compiling a generic procedure, the generic name is not entered in the symbol table, which then causes subsequent 'use' statements to fail. Example: in m_die.F90 we declare: module m_die use m_mpif90, only : MP_perr implicit none private ! except public :: die ! signal an exception interface die; module procedure & die0_, & ! die(where) die1_, & ! die(where,message) die2_, & ! die(where,proc,ier) die4_ ! die(where,mesg1,ival1,mesg2,ival2) end interface etc... Which compiles fine. In other files we try: subroutine IndexBin1_(n,indx,keys,bins,lcs,lns) use m_die, only : die ...and the compiler complains: use m_die, only : die 1 Error: Symbol 'die' referenced at (1) not found in module 'm_die' A quick check of the symbol table confirms the actual procedures are there, but the generic name is missing: 000009ba T ___m_die_MOD_die0_ 00000953 T ___m_die_MOD_die1_ 000008e5 T ___m_die_MOD_die2_ 00000862 T ___m_die_MOD_die4_ but no 'die'
(In reply to comment #0) > When compiling a generic procedure, the generic name is not entered in the > symbol table, which then causes subsequent 'use' statements to fail. > > Example: > > in m_die.F90 we declare: > > module m_die > use m_mpif90, only : MP_perr > implicit none > private ! except > > public :: die ! signal an exception > > interface die; module procedure & > die0_, & ! die(where) > die1_, & ! die(where,message) > die2_, & ! die(where,proc,ier) > die4_ ! die(where,mesg1,ival1,mesg2,ival2) > end interface > > etc... > Which compiles fine. > In other files we try: > > subroutine IndexBin1_(n,indx,keys,bins,lcs,lns) > use m_die, only : die > > ...and the compiler complains: > > use m_die, only : die > 1 > Error: Symbol 'die' referenced at (1) not found in module 'm_die' > > A quick check of the symbol table confirms the actual procedures are there, but > the generic name is missing: > 000009ba T ___m_die_MOD_die0_ > 00000953 T ___m_die_MOD_die1_ > 000008e5 T ___m_die_MOD_die2_ > 00000862 T ___m_die_MOD_die4_ > > > but no 'die' There is insufficient code here to try to reproduce your problem. Please attach a small self-contained example. It may also be advantageous to update your version of gfortran to 4.4.4, 4.5.0, or trunk.
Created attachment 21224 [details] three f90 files that reproduce the bug
I've investigated further, and can reproduce it, but with one more condition that I didn't mention in the original bugreport. Basically, it happens when we have two modules, both defining a subroutine with the same name, where one happens to use the other (with a renaming). For example: The module m_dropdead defines an interface 'die'. The module m_die also defines an interface 'die'. So far, so good, and both compile fine. However the subroutines in m_die use the die interface from m_dropdead: use m_dropdead, only : ddie => die Not a problem so far. But then, when I attempt to compile other files that use m_die, the compiler gets confused. For example, when compiling m_IndexBin_char, we get to the line: use m_die, only : die and the compiler complains that m_die doesn't have a die routine. It looks like a compiler bug - somehow or other the remapping to ddie in m_die has messed up the symbol table beyond the scope of the subroutine it was used in. I'm attaching three files that demonstrate the bug. If you remove the line that's commented out in m_die, and run them through gfortran, you should see it trip up when compiling m_IndexBin_char BTW I'm running gcc 4.3.0 On Mac OS X 10.5.8.
Created attachment 21225 [details] 2nd of three F90 files that reproduce the bug
Created attachment 21226 [details] 3rd file to reproduce - compiling this one generates the error
(In reply to comment #3) > I've investigated further, and can reproduce it, but with one more condition > that I didn't mention in the original bugreport. > Basically, it happens when we have two modules, both defining a subroutine with > the same name, where one happens to use the other (with a renaming). > For example: > > > The module m_dropdead defines an interface 'die'. > The module m_die also defines an interface 'die'. > > So far, so good, and both compile fine. > However the subroutines in m_die use the die interface from m_dropdead: > use m_dropdead, only : ddie => die > > Not a problem so far. > > But then, when I attempt to compile other files that use m_die, the compiler > gets confused. For example, when compiling m_IndexBin_char, we get to the line: > use m_die, only : die > and the compiler complains that m_die doesn't have a die routine. It looks like > a compiler bug - somehow or other the remapping to ddie in m_die has messed up > the symbol table beyond the scope of the subroutine it was used in. > > I'm attaching three files that demonstrate the bug. If you remove the line > that's commented out in m_die, and run them through gfortran, you should see it > trip up when compiling m_IndexBin_char What command line? With the renaming line uncommented, I see troutmask:sgk[209] gfc43 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 troutmask:sgk[210] rm *.mod troutmask:sgk[211] gfc44 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 troutmask:sgk[212] rm *.mod troutmask:sgk[213] gfc45 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 troutmask:sgk[214] rm *.mod troutmask:sgk[215] gfc4x -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 > BTW I'm running gcc 4.3.0 > On Mac OS X 10.5.8. Ah, here the potential problem, Mac OS X is notorious for having problems that other OS's do not.
Works for me too on x86_64-apple-darwin10.4 and powerpc-apple-darwin9. > Ah, here the potential problem, Mac OS X is notorious for having > problems that other OS's do not. urban legend!-)
Here's my command line, and the results: % gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 m_IndexBin_char.F90:12.25: use m_die, only : die 1 Error: Symbol 'die' referenced at (1) not found in module 'm_die' m_IndexBin_char.F90:18.25: use m_die, only : die 1 Error: Symbol 'die' referenced at (1) not found in module 'm_die' % gfortran -v Using built-in specs. Target: i386-apple-darwin9.0.0 Configured with: ../gcc-4.3-20071026/configure --enable-languages=fortran Thread model: posix gcc version 4.3.0 20071026 (experimental) (GCC)
(In reply to comment #8) > Here's my command line, and the results: > > % gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 > m_IndexBin_char.F90:12.25: > > use m_die, only : die > 1 > Error: Symbol 'die' referenced at (1) not found in module 'm_die' > m_IndexBin_char.F90:18.25: > > use m_die, only : die > 1 > Error: Symbol 'die' referenced at (1) not found in module 'm_die' > > % gfortran -v > Using built-in specs. > Target: i386-apple-darwin9.0.0 > Configured with: ../gcc-4.3-20071026/configure --enable-languages=fortran > Thread model: posix > gcc version 4.3.0 20071026 (experimental) (GCC) In that case, I think you need to update to a newer version of gfortran. gfc43 in my comment #6 is gcc version 4.3.6 20100622 (prerelease) (GCC) BUt, if you go with an upgrade, I'll suggest 4.4.x or even 4.5.x. These versions of course have many more bug fixes than in the 4.3.x branch.
Okay, I just upgraded to 4.4.1 and it compiles fine. Thanks!
Closing as WONTFIX. With trunk being for active development and 4.4 and 4.5 under maintenance commits, I doubt anyone will find time to investigate this further. Thanks for the bug report.