[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a

["burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-07-31 11:14 -------
> subroutine test2 (n, arr)
>   integer :: arr(n), n
> end subroutine test2

That example is valid as "n" is then implicitly typed as integer, which is
later confirmed. It only becomes invalid using:

  implicit none
or
  implicit real(a-z)

Note: Code such as
   subroutine sub(n,array)
     implicit none
     real    :: array(n)
     integer :: n
   end
can be found in several real-world codes. Such declarations should be allowed,
unless -std=* is given. (It is e.g. allowed by gfortran, ifort, sunf95,
g95,...; but not by NAG f95. I think those compilers which allow it also do not
warn with -std=*.)

> where in test2, reversing the order of the definition of arr(n) and n should
> make it work again.  Did I understand this correctly?

Yes (with above's implicit statements).

Another example, which works with gfortran, but is rejected by other compilers:

ifort:
hjf.f90(5): error #6361: An array-valued argument is required in this context. 
 [SIZE]
  integer :: b(size(a)), a(:)
--------------------^
hjf.f90(5): error #6435: This name has already been used in a specification
expression.   [A]
  integer :: b(size(a)), a(:)
-------------------------^

NAG: Error: line 3: SIZE of A used before its array declarator

g95: Error: Argument of SIZE intrinsic at (1) must be an array

(gfortran compiles and gives the expected result.)


subroutine sub(a)
   implicit none
   real    :: b(size(a)), a(:)
end

I think on should be able to do something like you proposed, but with -std=gnu
the above mentioned
  integer :: arr(n)
  integer :: n
should be still permitted (but it should be rejected with -std=f*).
See also: PR 34228.

In any case, for the example given in comment 0 we need to give an error (as
ifort or g95) or we need to get it working properly (as NAG f95) does. The
former solution seems to be cleaner and easier.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095