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.

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

Regards,

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

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.

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

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

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

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

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.

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

(snip)

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