I think I saw discussions on this topic already on c.l.f. I am having the following subroutine (and the recursive attribute doesn't play a role)
recursive function constr_quark_loopline(ho,sho) result(cl) integer, dimension(sho), intent(in) :: ho integer, dimension(sho) :: hor integer, intent(in) :: sho [...] end function constr_quark_loopline
Intel gives an error message error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name. [SHO]
in the case this is an external procedure, or a module procedure with or without 'implicit none' in the head of the module.
First of all, I would like to get it confirmed that this is really a contradiction of the standard, and that the order of the declarations matters. In case this is a module procedure without implicit none or an external procedure, implicit typing rules apply and sho would be considered to be a real, such that later specifying it as an integer is a contradiction. gfortran and nagfor complain:
integer, intent(in) :: sho
Error: Symbol ‘sho’ at (1) already has basic type of REAL
Error: rec.f90, line 8: Symbol SHO has already been implicitly typed
detected at SHO@<end-of-statement>
The strange thing (which seems a compiler bug to me) is that gfortran compiles this code when it is a module procedure with 'implicit none'. This seems a (gfortran) compiler bug to me. Comments are appreciated.
And yes, of course, I know that having the declaration of sho first solves all the problems, but this is 3rd-party code.
This is one aspect where compilers are (in my opinion, correctly so) tightening up on enforcing the rules of the standard. The following is a quotation from document 10-027 (F2008), Section 7.1.11, Specification expression:
3 7 A variable in a specification expression shall have its type and type parameters, if any, specified by a previous4 declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use5 association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any6 subsequent type declaration statement shall confirm the implied type and type parameters.
The dimension specifications are specification expressions. There are declaration ordering restrictions on specification expressions (and constant expressions) that are being violated here, that the program must follow, but which may not necessarily be diagnosed by a compiler - see F2008 7.1.11p7.
gfortran has an extension where it allows you to violate the standard's rules for declaration order in specification expressions. Intel Fortran doesn't have that extension (and the team was adamant that it was not going to add it, which I agreed with.) I am sure that gfortran would give you a complaint if you enabled standards checking.