Prev: Reason to deallocate out array
Next: Job opportunity for Fortran developer
From: analyst41 on 11 Jul 2010 09:07
I have been running code foreever that had

common /name1/var1,var2
common /name1/var3,var4,var5

in the same sub-program.

The intent was, of course, to call the second common /name2/.

I corrected it and the results are still the same, because
var3,var4,var5 occur only in that sub-program (I haven't gotten round
to doing whatever I was planning to do with var3-5.)

Why doesn't the compiler (Lahey) flag this as an error or at least as
a warning?
From: dpb on 11 Jul 2010 09:08
analyst41(a)hotmail.com wrote:
> I have been running code foreever that had
>
> common /name1/var1,var2
> common /name1/var3,var4,var5
>
> in the same sub-program.
>
> The intent was, of course, to call the second common /name2/.
>
> I corrected it and the results are still the same, because
> var3,var4,var5 occur only in that sub-program (I haven't gotten round
> to doing whatever I was planning to do with var3-5.)
>
> Why doesn't the compiler (Lahey) flag this as an error or at least as
> a warning?

Because it isn't???

"Any common block name (or blank common) can appear more than once in
one or more COMMON statements in a program unit. The list following each
successive appearance of the same common block name is treated as a
continuation of the list for the block associated with that name. "

Above from CVF documentation, not the Standard, but it is conforming
behavior if not the exact wording.

--
From: Gordon Sande on 11 Jul 2010 09:57
On 2010-07-11 10:08:21 -0300, dpb <none(a)non.net> said:

> analyst41(a)hotmail.com wrote:
>> I have been running code foreever that had
>>
>> common /name1/var1,var2
>> common /name1/var3,var4,var5
>>
>> in the same sub-program.
>>
>> The intent was, of course, to call the second common /name2/.
>>
>> I corrected it and the results are still the same, because
>> var3,var4,var5 occur only in that sub-program (I haven't gotten round
>> to doing whatever I was planning to do with var3-5.)
>>
>> Why doesn't the compiler (Lahey) flag this as an error or at least as
>> a warning?
>
> Because it isn't???
>
> "Any common block name (or blank common) can appear more than once in
> one or more COMMON statements in a program unit. The list following
> each successive appearance of the same common block name is treated as
> a continuation of the list for the block associated with that name. "
>
> Above from CVF documentation, not the Standard, but it is conforming
> behavior if not the exact wording.

Except all the various references to the common block named name1
should be of the
same size. Not enforcing this is a common extension.

From: dpb on 11 Jul 2010 10:27
Gordon Sande wrote:
> On 2010-07-11 10:08:21 -0300, dpb <none(a)non.net> said:
>
....

>> "Any common block name (or blank common) can appear more than once in
>> one or more COMMON statements in a program unit. The list following
>> each successive appearance of the same common block name is treated as
>> a continuation of the list for the block associated with that name. "
>>
>> Above from CVF documentation, not the Standard, but it is conforming
>> behavior if not the exact wording.
>
> Except all the various references to the common block named name1 should
> be of the same size. Not enforcing this is a common extension.

To clarify, the _TOTAL_ length of the named common entity must be the
same in different program units but the references _within_ a given
program unit of pieces comprising the whole is not an extension nor does
it violate Standard.

Given that the requirement for consistency in size is across different
program units I'm sure it's not required to be diagnosed altho linker
maps will be able to see mismatches and program units compiled together
or compilers with facility for extended range analysis can as well.

But, the code posted is perfectly legal and not any extension.

Now, if it had been

common /name1/var1,var2
common /name1/var3,var4,var5

in subprogram A and

common /name1/var1,var2
common /name2/var3,var4,var5

in subprogram B, then indeed, "Houston. We have a problem."


--
From: Gordon Sande on 11 Jul 2010 10:47
On 2010-07-11 11:27:17 -0300, dpb <none(a)non.net> said:

> Gordon Sande wrote:
>> On 2010-07-11 10:08:21 -0300, dpb <none(a)non.net> said:
>>
> ...
>
>>> "Any common block name (or blank common) can appear more than once in
>>> one or more COMMON statements in a program unit. The list following
>>> each successive appearance of the same common block name is treated as
>>> a continuation of the list for the block associated with that name. "
>>>
>>> Above from CVF documentation, not the Standard, but it is conforming
>>> behavior if not the exact wording.
>>
>> Except all the various references to the common block named name1
>> should be of the same size. Not enforcing this is a common extension.
>
> To clarify, the _TOTAL_ length of the named common entity must be the
> same in different program units but the references _within_ a given
> program unit of pieces comprising the whole is not an extension nor
> does it violate Standard.

There will only be one reference to a common block within a probram unit
even if the reference is the result of several statements with several
lexographic occuurrances of the name because of the use of the
concatenation feature of
the syntax for commons.

> Given that the requirement for consistency in size is across different
> program units I'm sure it's not required to be diagnosed altho linker
> maps will be able to see mismatches and program units compiled together
> or compilers with facility for extended range analysis can as well.

Very few linkers notice with some taking the longest and others the
first reference to
the named common.

> But, the code posted is perfectly legal and not any extension.
>
> Now, if it had been
>
> common /name1/var1,var2
> common /name1/var3,var4,var5
>
> in subprogram A and
>
> common /name1/var1,var2
> common /name2/var3,var4,var5
>
> in subprogram B, then indeed, "Houston. We have a problem."


 |  Next  |  Last
Pages: 1 2 3
Prev: Reason to deallocate out array
Next: Job opportunity for Fortran developer