Fortran - Conformance question involving equivalence

Author

Conformance question involving equivalence

Steven G. Kargl

2004-07-14, 3:57 am

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

Arjen Markus

2004-07-14, 3:57 am

"Steven G. Kargl" wrote:
>
> 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

Nick Maclaren

2004-07-14, 3:57 am

In article <40F4D83A.ED5402C4@wldelft.nl>,
Arjen Markus <arjen.markus@wldelft.nl> writes:
|> "Steven G. Kargl" wrote:
|> >
|> > 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.

Arjen Markus

2004-07-14, 8:58 am

Nick Maclaren wrote:
>

>
> |> 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

glen herrmannsfeldt

2004-07-14, 8:58 am

Arjen Markus wrote:

> "Steven G. Kargl" wrote:

[color=darkred]
[color=darkred]
[color=darkred]
> 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

Nick Maclaren

2004-07-14, 8:58 am

In article <40F4E6BB.96478C0C@wldelft.nl>,
Arjen Markus <arjen.markus@wldelft.nl> writes:
|> >
|> > |> 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.

Klaus Wacker

2004-07-14, 8:58 am

Arjen Markus <arjen.markus@wldelft.nl> wrote:
> "Steven G. Kargl" wrote:
>
> 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.

--
Klaus Wacker wacker@Physik.Uni-Dortmund.DE
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

Nick Maclaren

2004-07-14, 8:58 am

In article <636Jc.74820$%_6.67723@attbi_s01>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
|>
|> 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.

glen herrmannsfeldt

2004-07-14, 8:58 am

Nick Maclaren wrote:

> In article <636Jc.74820$%_6.67723@attbi_s01>,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> |> 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

Nick Maclaren

2004-07-14, 8:58 am

In article <hn7Jc.76579$IQ4.22275@attbi_s02>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
|>
|> > |> 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.

Richard Maine

2004-07-14, 4:00 pm

Klaus Wacker <wacker@physik.uni-dortmund.de> writes:

> 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

Nick Maclaren

2004-07-14, 4:00 pm

In article <m1u0war555.fsf@macfortran.local>,
Richard Maine <nospam@see.signature> writes:
|>
|> 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.

Steven G. Kargl

2004-07-14, 8:57 pm

In article <40F4D83A.ED5402C4@wldelft.nl>,
Arjen Markus <arjen.markus@wldelft.nl> writes:
> "Steven G. Kargl" wrote:
>
> 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.

> 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
http://troutmask.apl.washington.edu/~kargl/

Steven G. Kargl

2004-07-14, 8:57 pm

In article <m1u0war555.fsf@macfortran.local>,
Richard Maine <nospam@see.signature> writes:
> Klaus Wacker <wacker@physik.uni-dortmund.de> writes:
>
>
> 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
http://troutmask.apl.washington.edu/~kargl/

glen herrmannsfeldt

2004-07-15, 3:59 pm

Richard Maine wrote:

(snip)

> 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)

> 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

Richard Maine

2004-07-15, 9:00 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

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

For extra excitement, add the old ASSIGN statement into the mix... and
be sure to think about implementations where addresses are not the same
size as integers. The term "shadow variable" might be of some help
here. Then read the standard very carefully to figure out what
behavior it really guarantees with such a mix. :-(

--
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

glen herrmannsfeldt

2004-07-15, 9:00 pm

Richard Maine wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

[color=darkred]
> For extra excitement, add the old ASSIGN statement into the mix... and
> be sure to think about implementations where addresses are not the same
> size as integers. The term "shadow variable" might be of some help
> here. Then read the standard very carefully to figure out what
> behavior it really guarantees with such a mix. :-(

I might have used ASSIGN once or twice, but not in COMMON.

Some years ago I was interested in converting BASIC programs
to Fortran, and had to implement the GOSUB statement somehow.
I might have done it with ASSIGNed GOTO. (It might be that
there were no nested GOSUBs in those programs.) Learning
Fortran first, and then BASIC, seems to have given me
different ideas about what could be done.

As far as I remember, you aren't supposed to use ASSIGNed GOTO
between different subroutines. For comparison purposes only,
note that PL/I has statement label variables, and it is legal
to GOTO back in the CALL tree. C has setjmp/longjmp with
similar functionality.

-- glen

Richard Maine

2004-07-15, 9:00 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> I might have used ASSIGN once or twice, but not in COMMON.
....
> As far as I remember, you aren't supposed to use ASSIGNed GOTO
> between different subroutines.

You aren't. But one might still think to use ASSIGN with a
variable in COMMON just to get thee effect of SAVE semantics,
even though f66 didn't call it that. (ASSIGN being f66, there
wasn't any other way to get it).

I don't want to go read the fine print enough to recall whether
that is guaranteed to work or not. I think read it once, but
I forget the answer, and it requires careful enough reading that
I sure don't feel like doing it right now. I think the answer
was "no", but I'm not at all sure of that.

--
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

Sponsored Links