Conformance question involving equivalence
Author Message
Conformance question involving equivalence

Does the following code conform to any version of a fortran
standard?

SUBROUTINE SUB(A)
COMMON /INFO/ IARRAY(1000)
EQUIVALENCE (M,IARRAY(100)), (N,IARRAY(200))
REAL A(M,N)
A(1,1) = A(2,2)
END

The question is whether EQUIVALENCE is allowed to define
the values of the array bounds of the dummy argument A.

--
Steve

Sun, 31 Dec 2006 12:28:29 GMT
Conformance question involving equivalence

Quote:

> Does the following code conform to any version of a Fortran
> standard?

>       SUBROUTINE SUB(A)
>       COMMON /INFO/ IARRAY(1000)
>       EQUIVALENCE (M,IARRAY(100)), (N,IARRAY(200))
>       REAL A(M,N)
>       A(1,1) = A(2,2)
>       END

> The question is whether EQUIVALENCE is allowed to define
> the values of the array bounds of the dummy argument A.

> --
> Steve

Superficially, I would say, that this is legal in Fortran 90
and onwards, as A is dimensioned at the start of the subroutine
and any changes to M and N will not affect it anymore.

Mind you, this code does not strike me as very attractive from
a maintenance point of view ...

Regards,

Arjen

Sun, 31 Dec 2006 14:52:42 GMT
Conformance question involving equivalence

|> >
|> > Does the following code conform to any version of a Fortran
|> > standard?
|> >
|> >       SUBROUTINE SUB(A)
|> >       COMMON /INFO/ IARRAY(1000)
|> >       EQUIVALENCE (M,IARRAY(100)), (N,IARRAY(200))
|> >       REAL A(M,N)
|> >       A(1,1) = A(2,2)
|> >       END
|> >
|> > The question is whether EQUIVALENCE is allowed to define
|> > the values of the array bounds of the dummy argument A.
|>
|> Superficially, I would say, that this is legal in Fortran 90
|> and onwards, as A is dimensioned at the start of the subroutine
|> and any changes to M and N will not affect it anymore.

That is how I read it, too.

|> Mind you, this code does not strike me as very attractive from
|> a maintenance point of view ...

Except to ensure the employment of future generations of Fortran
programmers :-)  Furthermore, combine that construction with the
use of OpenMP and some other thread updating IARRAY, and you have
a recipe for almost unfindable bugs.

Regards,
Nick Maclaren.

Sun, 31 Dec 2006 15:37:56 GMT
Conformance question involving equivalence

Quote:

> |> Mind you, this code does not strike me as very attractive from
> |> a maintenance point of view ...

> Except to ensure the employment of future generations of Fortran
> programmers :-)  Furthermore, combine that construction with the
> use of OpenMP and some other thread updating IARRAY, and you have
> a recipe for almost unfindable bugs.

Hm, I will keep it in mind for the next time I am in desperate
need of something to do ... (MPI is gaining popularity here)

Regards,

Arjen

Sun, 31 Dec 2006 15:54:35 GMT
Conformance question involving equivalence

Quote:

>>Does the following code conform to any version of a Fortran
>>standard?
>>      SUBROUTINE SUB(A)
>>      COMMON /INFO/ IARRAY(1000)
>>      EQUIVALENCE (M,IARRAY(100)), (N,IARRAY(200))
>>      REAL A(M,N)
>>      A(1,1) = A(2,2)
>>      END
>>The question is whether EQUIVALENCE is allowed to define
>>the values of the array bounds of the dummy argument A.
> Superficially, I would say, that this is legal in Fortran 90
> and onwards, as A is dimensioned at the start of the subroutine
> and any changes to M and N will not affect it anymore.

(snip)

EQUIVALENCE to something in COMMON is as good as being in COMMON.

I am not sure, though, that F66 allows adjustable dimensions
to come from COMMON.  The OS/360 Fortran manual seems to allow
it, and doesn't shade it as is supposed to be done for extensions.

On the other hand, I don't see in F66 where it is allowed.
Normally M and N should be parameters to SUB.

In any case, if it is allowed, the appropriate values
must be assigned to M and N before calling, they must be
at least 2, and must not change in the subroutine.
The actual argument must be large enough, too.

-- glen

Sun, 31 Dec 2006 16:22:26 GMT
Conformance question involving equivalence

|> >
|> > |> Mind you, this code does not strike me as very attractive from
|> > |> a maintenance point of view ...
|> >
|> > Except to ensure the employment of future generations of Fortran
|> > programmers :-)  Furthermore, combine that construction with the
|> > use of OpenMP and some other thread updating IARRAY, and you have
|> > a recipe for almost unfindable bugs.
|>
|> Hm, I will keep it in mind for the next time I am in desperate
|> need of something to do ... (MPI is gaining popularity here)

We have been an MPI shop for a long time, but I was at ISC2004,
and noted that it was referred to by the sort of person who would
previously not have heard of it.  OpenMP seems to be receding,
probably as people try to debug and tune programs using it :-(

This isn't totally off-topic, as the same problems would arise
with MPI non-blocking primitives - and perhaps MPI derived types.
Fortran 200x 'volatile' seems to be what is needed for the former,
but I am not convinced that it will be usable for the purpose, any
more than it is in C (despite being a better specification).

Regards,
Nick Maclaren.

Sun, 31 Dec 2006 16:25:10 GMT
Conformance question involving equivalence

Quote:

>> Does the following code conform to any version of a Fortran
>> standard?

>>       SUBROUTINE SUB(A)
>>       COMMON /INFO/ IARRAY(1000)
>>       EQUIVALENCE (M,IARRAY(100)), (N,IARRAY(200))
>>       REAL A(M,N)
>>       A(1,1) = A(2,2)
>>       END

>> The question is whether EQUIVALENCE is allowed to define
>> the values of the array bounds of the dummy argument A.

>> --
>> Steve

> Superficially, I would say, that this is legal in Fortran 90
> and onwards, as A is dimensioned at the start of the subroutine
> and any changes to M and N will not affect it anymore.

I think it could have already been legal in Fortran 77. As the array
is passed in as an argument, no dynamic memory allocation is
necessary. However, the standard says:

| A variable name that appears in a dimension bound expression of an
| array must also appear as a name either in every dummy argument list
| that contains the array name or in a common block in that subprogram.

The phrase "as a name" seems to exclude the association to a common
via equivalence.

--

Experimentelle Physik V   http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund     Tel.: +49 231 755 3587
D-44221 Dortmund          Fax:  +49 231 755 4547

Sun, 31 Dec 2006 16:33:28 GMT
Conformance question involving equivalence

|>
|> EQUIVALENCE to something in COMMON is as good as being in COMMON.
|>
|> I am not sure, though, that F66 allows adjustable dimensions
|> to come from COMMON.  The OS/360 Fortran manual seems to allow
|> it, and doesn't shade it as is supposed to be done for extensions.
|>
|> On the other hand, I don't see in F66 where it is allowed.
|> Normally M and N should be parameters to SUB.

That is correct; they must be.  It was a Fortran IV extension,
and was not allowed in Fortran 66.  Section 7.2.1.1.2.

|> In any case, if it is allowed, the appropriate values
|> must be assigned to M and N before calling, they must be
|> at least 2, and must not change in the subroutine.
|> The actual argument must be large enough, too.

Yes.

Regards,
Nick Maclaren.

Sun, 31 Dec 2006 16:36:28 GMT
Conformance question involving equivalence

Quote:

> |> EQUIVALENCE to something in COMMON is as good as being in COMMON.
> |> I am not sure, though, that F66 allows adjustable dimensions
> |> to come from COMMON.  The OS/360 Fortran manual seems to allow
> |> it, and doesn't shade it as is supposed to be done for extensions.
> |> On the other hand, I don't see in F66 where it is allowed.
> |> Normally M and N should be parameters to SUB.
> That is correct; they must be.  It was a Fortran IV extension,
> and was not allowed in Fortran 66.  Section 7.2.1.1.2.

The most common correction when a new revision of the manual
comes out is corrections for the shading of extensions.
Maybe I should send in the comment form at the back to notify
them of this one.

-- glen

Sun, 31 Dec 2006 17:52:17 GMT
Conformance question involving equivalence

|>
|> > |> I am not sure, though, that F66 allows adjustable dimensions
|> > |> to come from COMMON.  The OS/360 Fortran manual seems to allow
|> > |> it, and doesn't shade it as is supposed to be done for extensions.
|>
|> > |> On the other hand, I don't see in F66 where it is allowed.
|> > |> Normally M and N should be parameters to SUB.
|>
|> > That is correct; they must be.  It was a Fortran IV extension,
|> > and was not allowed in Fortran 66.  Section 7.2.1.1.2.
|>
|> The most common correction when a new revision of the manual
|> comes out is corrections for the shading of extensions.
|> Maybe I should send in the comment form at the back to notify
|> them of this one.

About 10-15 years ago, I reported a bug in VS Fortran to do with
it mishandling object files produced by Fortran G.  They eventually
came back and said that they couldn't find a manual within IBM, so
I sent them the relevant information.  They fixed the bug :-)

Please tell me how you get on ....

Regards,
Nick Maclaren.

Sun, 31 Dec 2006 18:03:46 GMT
Conformance question involving equivalence

Quote:

> I think it could have already been legal in Fortran 77. As the array
> is passed in as an argument, no dynamic memory allocation is
> necessary. However, the standard says:

> | A variable name that appears in a dimension bound expression of an
> | array must also appear as a name either in every dummy argument list
> | that contains the array name or in a common block in that subprogram.

> The phrase "as a name" seems to exclude the association to a common
> via equivalence.

I find that phrase a little strange in general.  After all, a name
isn't in a common block.  A name is in a common statement, but not
a common block.  I'd be tempted to interpret that as the variable
being in the common block.  But I guess I don't find it definitive.

The f90 standard is a little more clear here.  The corresponding
requirement for a specification expression is

"A variable that is in a common block or a variable that is the subobject
of a variable in a common block."

No funniness about names being in common blocks.  I'd say that the
equivalenced variable is probably alsso "in" the common block,
though the precise definition of common blocks is tricky indeed
(I'm occasionally amazed at the people who mention how simple
common is - I think they mostly don't understand its real definition,
but only how simple it can be if you restrict yourself to simple
use of it...which isn't a bad idea).  Hmm... Ah. I'm slighly surprised,
but I do manage to find the words to cover this pretty much in exactly
the form needed.  F90 5.5.2.1(2)

"Data objects associated with an entity in a common block are considered
to be in that common block."

So I think I'll go with "clearly" legal in f90, but subject to debate
in f77.  Since you aren't going to get a formal f77 interp any more,
that's probably how it will have to stand.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Sun, 31 Dec 2006 23:16:06 GMT
Conformance question involving equivalence

|>
|> So I think I'll go with "clearly" legal in f90, but subject to debate
|> in f77.  Since you aren't going to get a formal f77 interp any more,
|> that's probably how it will have to stand.

And  clearly illegal in Fortran 66, which you are even less likely
to get a formal interpretation of :-)

I know of one way in which you could get a formal interpretation
of Fortran 77, which is by finding a new incompatibility with
Fortran 90 and quoting the committment to upwards compatibility.

Regards,
Nick Maclaren.

Mon, 01 Jan 2007 00:23:20 GMT
Conformance question involving equivalence

Quote:

>> Does the following code conform to any version of a Fortran
>> standard?

>>       SUBROUTINE SUB(A)
>>       COMMON /INFO/ IARRAY(1000)
>>       EQUIVALENCE (M,IARRAY(100)), (N,IARRAY(200))
>>       REAL A(M,N)
>>       A(1,1) = A(2,2)
>>       END

>> The question is whether EQUIVALENCE is allowed to define
>> the values of the array bounds of the dummy argument A.

> Superficially, I would say, that this is legal in Fortran 90
> and onwards, as A is dimensioned at the start of the subroutine
> and any changes to M and N will not affect it anymore.

Thanks for the input.

Quote:
> Mind you, this code does not strike me as very attractive from
> a maintenance point of view ...

I can assure that I do not write code like the above.  This is
from the old g77 test suite and the new gfortran was issuing an
error.  I have NAG's compiler and it had no problems with the
code.  I tried to read a draft of the F2003 stanadrd, but
came away with more questions than answer.

--
Steve

Mon, 01 Jan 2007 05:50:16 GMT
Conformance question involving equivalence

Quote:

>> I think it could have already been legal in Fortran 77. As the array
>> is passed in as an argument, no dynamic memory allocation is
>> necessary. However, the standard says:

>> | A variable name that appears in a dimension bound expression of an
>> | array must also appear as a name either in every dummy argument list
>> | that contains the array name or in a common block in that subprogram.

>> The phrase "as a name" seems to exclude the association to a common
>> via equivalence.

> I find that phrase a little strange in general.  After all, a name
> isn't in a common block.  A name is in a common statement, but not
> a common block.  I'd be tempted to interpret that as the variable
> being in the common block.  But I guess I don't find it definitive.

> The f90 standard is a little more clear here.  The corresponding
> requirement for a specification expression is

>   "A variable that is in a common block or a variable that is the subobject
>    of a variable in a common block."

> No funniness about names being in common blocks.  I'd say that the
> equivalenced variable is probably alsso "in" the common block,
> though the precise definition of common blocks is tricky indeed
> (I'm occasionally amazed at the people who mention how simple
> common is - I think they mostly don't understand its real definition,
> but only how simple it can be if you restrict yourself to simple
> use of it...which isn't a bad idea).  Hmm... Ah. I'm slighly surprised,
> but I do manage to find the words to cover this pretty much in exactly
> the form needed.  F90 5.5.2.1(2)

>   "Data objects associated with an entity in a common block are considered
>    to be in that common block."

> So I think I'll go with "clearly" legal in f90, but subject to debate
> in f77.  Since you aren't going to get a formal f77 interp any more,
> that's probably how it will have to stand.

Thanks for the input, Richard.  I never used EQUIVALENCE and haven't
used a COMMON statement since I learned about modules.  So, I tried
reading a draft of the F2003 standard to determine the legality of
the code.  Needless to say, I came away scratching my head because
I don't speak standardese.

--
Steve

Mon, 01 Jan 2007 05:57:19 GMT
Conformance question involving equivalence

(snip)

Quote:
> I find that phrase a little strange in general.  After all, a name
> isn't in a common block.  A name is in a common statement, but not
> a common block.  I'd be tempted to interpret that as the variable
> being in the common block.  But I guess I don't find it definitive.

(snip)

Quote:
> No funniness about names being in common blocks.  I'd say that the
> equivalenced variable is probably alsso "in" the common block,
> though the precise definition of common blocks is tricky indeed
> (I'm occasionally amazed at the people who mention how simple
> common is - I think they mostly don't understand its real definition,
> but only how simple it can be if you restrict yourself to simple
> use of it...which isn't a bad idea).

Well, I always just figure out how they should be arranged
in memory.  If they can't be arranged to satisfy the EQUIVALENCE
then it is illegal.  It is also illegal if any variables would be
before the beginning of the COMMON block.  The actual length
depends on the last variable in the COMMON statement, or in any
array EQUIVALENCEd directly or indirectly to a variable in COMMON.

But I agree that many of the complications of EQUIVALENCE
and COMMON are better not used.

-- glen

Tue, 02 Jan 2007 03:48:25 GMT

 Page 1 of 2 [ 18 post ] Go to page: [1] [2]

Relevant Pages