named common and subprogram names
in [Fortran]
|
Prev: Error when compiling using gcc440 (compiles fine with gcc412)- missing actual arg:
Next: Caveat: Can One Dim Local Arrays Using Argument List Integers ??
From: glen herrmannsfeldt on 18 Dec 2009 13:23 stevenb <stevenb.gcc(a)gmail.com> wrote: > On Dec 17, 2:45?pm, m_b_metcalf <michaelmetc...(a)compuserve.com> wrote: (snip) >> program main >> common/junk/i >> i =1 >> print *, i >> end program main >> subroutine junk >> a = 0.0 >> end (snip) > I think most compilers catch this before the linker. gfortran > gives me this: (snip) > Error: Global name 'junk' at (1) is already being used as a COMMON at Now put the subroutine call and subroutine in a separate file from the common, compile them separately, and link the two object files. -- glen
From: steve on 18 Dec 2009 13:32 On Dec 18, 10:23 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > stevenb <stevenb....(a)gmail.com> wrote: > > On Dec 17, 2:45?pm, m_b_metcalf <michaelmetc...(a)compuserve.com> wrote: > > (snip) > > >> program main > >> common/junk/i > >> i =1 > >> print *, i > >> end program main > >> subroutine junk > >> a = 0.0 > >> end > > (snip) > > > I think most compilers catch this before the linker. gfortran > > gives me this: > > (snip) > > > Error: Global name 'junk' at (1) is already being used as a COMMON at > > Now put the subroutine call and subroutine in a separate file from > the common, compile them separately, and link the two object files. troutmask:sgk[216] cat b.f90 c.f90 ! ! This is b.f90. ! program b implicit none real x common /junk/x x = 42. call sub print *, x end program ! ! This is c.f90. ! subroutine sub call junk end subroutine sub subroutine junk print *, 'junk here' end subroutine junk [1] + Done nedit b.f90 c.f90 troutmask:sgk[217] gfc4x -c c.f90 troutmask:sgk[218] gfc4x -o z b.f90 c.o /usr/bin/ld: Warning: alignment 4 of symbol `junk_' in c.o is smaller than 16 in /tmp/cckmfCbH.o /usr/bin/ld: Warning: size of symbol `junk_' changed from 4 in /tmp/ cckmfCbH.o to 109 in c.o /usr/bin/ld: Warning: type of symbol `junk_' changed from 1 to 2 in c.o troutmask:sgk[219] ./z Segmentation fault (core dumped) It's probably a fairly good idea to not ignore the linker warning. -- steve
From: Tim Prince on 19 Dec 2009 14:29
mecej4 wrote: > Tim Prince wrote: >> glen herrmannsfeldt wrote: >>> m_b_metcalf <michaelmetcalf(a)compuserve.com> wrote: >>>> On Dec 17, 11:33?am, "analys...(a)hotmail.com" <analys...(a)hotmail.com> >>>> wrote: >>>>> I just had an issue (crash) with LF95 because a named common block >>>>> had the same name as a subprogram. >>> >>>>> What does the standard say? >>> >>>> It says Lahey's right (not to crash, but to diagnose the clash). >>> >>> If they are both referenced in one routine then I suppose I would >>> expect the compiler to notice. If they are referenced in different >>> routines, then on many systems it is up to the linker to notice. >>> >>> I do remember that on OS/360, both subroutines and initialized >>> (in BLOCK DATA) COMMON blocks are both SD (that is what they are >>> called by the linker), where unintialized COMMON is CM. As they >>> look the same, there is no possibility for the linker to notice. >>> >>> -- glen >> In the first implementation of f77 of which I had experience, the only >> known way to simulate system_clock was to initialize a labeled COMMON >> by setting the octal code in BLOCK DATA, then CALL the labeled >> COMMON. The compiler had no checks to inhibit this hack. > > That reminds me of an early CPM/86 C compiler which, for code such as > > ... > int Var[3]; > main(){ > int i; > ... > i=Var(1); > ... > } > > where I had used () in place of [] because of Fortran habits, the > compiled code contained a call to Var, which resulted in executing data. > > -- mecej4 Yes, we made CP/M-80 system calls in Microsoft Fortran by skipping the setting of a function return value, which had the effect of returning the address of the argument. Thus, we had the effect of LOC() without writing asm code. |