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?

Thanks.

On Dec 17, 11:33=A0am, "analys...@hotmail.com" <analys...@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?
>
> Thanks.

It says Lahey's right (not to crash, but to diagnose the clash).

Regards,

Mike Metcalf

m_b_metcalf <michaelmetcalf@compuserve.com> wrote:
> On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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

On Dec 17, 1:55=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> m_b_metcalf <michaelmetc...@compuserve.com> wrote:
> > On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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. =A0If they are referenced in different
> routines, then on many systems it is up to the linker to notice.
>

program main
common/junk/i
i =3D1
print *, i
end program main
subroutine junk
a =3D 0.0
end

Error	1	 Error: Declaration of globally visible name conflicts with a
common block declaration

A matter of quality of implementation.

Regards,

Mike Metcalf

P.S. That was Intel.

glen herrmannsfeldt wrote:
> m_b_metcalf <michaelmetcalf@compuserve.com> wrote:
>> On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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.

Tim Prince wrote:
> glen herrmannsfeldt wrote:
>> m_b_metcalf <michaelmetcalf@compuserve.com> wrote:
>>> On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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

analyst41@hotmail.com wrote in message
<455d054f-f3ec-4337-9eea-61045d6ca26c@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.

On Dec 17, 2:45=A0pm, m_b_metcalf <michaelmetc...@compuserve.com> wrote:
> On Dec 17, 1:55=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > m_b_metcalf <michaelmetc...@compuserve.com> wrote:
> > > On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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. =A0If they are referenced in different
> > routines, then on many systems it is up to the linker to notice.
>
> program main
> common/junk/i
> i =3D1
> print *, i
> end program main
> subroutine junk
> a =3D 0.0
> end
>
> Error =A0 1 =A0 =A0 =A0 =A0Error: 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@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

On 2009-12-18 10:38:10 -0400, stevenb <stevenb.gcc@gmail.com> said:

> On Dec 17, 2:45�pm, m_b_metcalf <michaelmetc...@compuserve.com> wrote:
>> On Dec 17, 1:55�pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> 
>>> m_b_metcalf <michaelmetc...@compuserve.com> wrote:
>>>> On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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@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.

stevenb <stevenb.gcc@gmail.com> wrote:
> On Dec 17, 2:45?pm, m_b_metcalf <michaelmetc...@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

On Dec 18, 10:23=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> stevenb <stevenb....@gmail.com> wrote:
> > On Dec 17, 2:45?pm, m_b_metcalf <michaelmetc...@compuserve.com> wrote:
>
> (snip)
>
> >> program main
> >> common/junk/i
> >> i =3D1
> >> print *, i
> >> end program main
> >> subroutine junk
> >> a =3D 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 =3D 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

mecej4 wrote:
> Tim Prince wrote:
>> glen herrmannsfeldt wrote:
>>> m_b_metcalf <michaelmetcalf@compuserve.com> wrote:
>>>> On Dec 17, 11:33?am, "analys...@hotmail.com" <analys...@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.

On 12/17/2009 5:33 AM, analyst41@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?

The standard says that having a subprogram and a named common block with 
the same name is not allowed.

-- 
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
   http://software.intel.com/en-us/forums/
Intel Software Development Products Support
   http://software.intel.com/sites/support/
My Fortran blog
   http://www.intel.com/software/drfortran