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: Tim Prince on 17 Dec 2009 10:25 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.
From: mecej4 on 17 Dec 2009 11:50 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
From: robin on 18 Dec 2009 00:16 analyst41(a)hotmail.com wrote in message <455d054f-f3ec-4337-9eea-61045d6ca26c(a)u7g2000yqm.googlegroups.com>... >I just had an issue (crash) with LF95 because a named common block had >the same name as a subprogram. The name in a named COMMON block is an external name. A subprogram name is an external name. >What does the standard say? The same that it says about having two subroutines with the same name. >Thanks.
From: stevenb on 18 Dec 2009 09:38 On Dec 17, 2:45 pm, m_b_metcalf <michaelmetc...(a)compuserve.com> wrote: > On Dec 17, 1:55 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > > m_b_metcalf <michaelmetc...(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. > > program main > common/junk/i > i =1 > print *, i > end program main > subroutine junk > a = 0.0 > end > > Error 1 Error: Declaration of globally visible name conflicts with a > common block declaration > > A matter of quality of implementation. I think most compilers catch this before the linker. gfortran gives me this: stevenb(a)iowa:~$ gfortran t.f90 t.f90:6.15: subroutine junk 1 t.f90:2.12: common/junk/i 2 Error: Global name 'junk' at (1) is already being used as a COMMON at (2) Ciao! Steven
From: Gordon Sande on 18 Dec 2009 10:12
On 2009-12-18 10:38:10 -0400, stevenb <stevenb.gcc(a)gmail.com> said: > On Dec 17, 2:45�pm, m_b_metcalf <michaelmetc...(a)compuserve.com> wrote: >> On Dec 17, 1:55�pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: >> >>> m_b_metcalf <michaelmetc...(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. >> >> program main >> common/junk/i >> i =1 >> print *, i >> end program main >> subroutine junk >> a = 0.0 >> end >> >> Error � 1 � � � �Error: Declaration of globally visible name co > nflicts with a >> common block declaration >> >> A matter of quality of implementation. > > I think most compilers catch this before the linker. gfortran gives me > this: > > > stevenb(a)iowa:~$ gfortran t.f90 > t.f90:6.15: > > subroutine junk > 1 > t.f90:2.12: > > common/junk/i > 2 > Error: Global name 'junk' at (1) is already being used as a COMMON at > (2) > > > Ciao! > Steven This relies on the compiler seeing both names in a single source file. The style of a separate source file for each routine defeats this. The style goes with the use of make to control compilation cascades. Then it is back the the old problem of what the linker can do and the awkwardness of how to get the linker to find block data units in libraries. My guess is that the original poster's problem was not actually a crash in the compiler but a crash with their program when it tried to execute. As such the name of the vendor was of no import as any other vendor would have had the same problem with separate source files and a weak linker. |