[Patch, Fortran] PR fortran/37688: Relax "used before typed" check

Tobias Burnus burnus@net-b.de
Sun Oct 12 12:41:00 GMT 2008


Paul Richard Thomas wrote:
> Which other compilers accept this feature
g95 (-std=f95), ifort (-stand f95), openf95, sunf95, gfortran (-std=f95
-pedantic) 4.1, 4.2 and 4.3 [but not 4.4].

> and why is it so unreasonable to place declarations in standard
> conforming order?
I can tell you why it happens: Assuming a

   subroutine mysubroutine (x, y , n)

then it is natural to declare the variables in the order (x, y, n)
instead of (n, x, y) or (n, y, x). And it is quite natural to have the
order <array>, <size> in the argument list - after all one writes A(n)
in programs or  A \in Mat(n x n) in mathematics. If I look at LAPACK it
also has:

   subroutine dgeqrf(m,n,A,lda,Tau,Work,lwork,info)

where lda is used in A(lda,n) and lwork by work(lwork). (Well, the
original LAPACK declaration uses "*" everywhere).

> I am completely against bending the standard on the grounds that
> something is "used in real world code". As very least, do a standard
> check on it and preferably don't do it at all.
The standard check was added by Daniel's initial patch for 4.4 did. With
-std=f* even

  implicit none
  real :: A(n)
  integer :: n

gets rejected. (That is what the "strict" checking is for; gfortran <
4.4 had no such check at all.)


In general I would like that all programs are compilable which can be
compiled by several other compilers (either by default or as e.g. for
-f[no-]range-check with an error message which points to that option)
and I would like to have good diagnostics either as warning or (esp.
with -std=f*) as error if something is invalid according to the Fortran
standard. The former is useful for users of code, which just want to get
it running; the latter is useful for people developing Fortran programs.
-- Actually, best would be a stricter checks for developers and laxer
for mere users, but detecting this automatically is not so easy. ;-)
For Fortran 2003/2008 features one can be stricter as there is not so
much legacy code around and gfortran has enough market share to push
developers to standard conforming code (e.g. gfortran does not allow len
> 1 for character dummy arguments of bind(C) procedures, which is
required by the standard but not in line with other compilers).

I think the patch is thus reasonable, but I don't feel strong about it.

Tobias



More information about the Gcc-patches mailing list