Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28383 Discussions

Order of declaration statements with and without implicit typing

Juergen_R_R
Valued Contributor I
1,178 Views

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  
                                            1
Error: Symbol ‘sho’ at (1) already has basic type of REAL

and

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.

 

0 Kudos
4 Replies
mecej4
Honored Contributor III
1,178 Views

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 specifi cation expression shall have its type and type parameters, if any, speci fied by a previous
4    declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use
5    association. If a variable in a specifi cation expression is typed by the implicit typing rules, its appearance in any
6    subsequent type declaration statement shall confi rm the implied type and type parameters.

 

0 Kudos
IanH
Honored Contributor II
1,178 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
1,178 Views

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.

0 Kudos
Juergen_R_R
Valued Contributor I
1,178 Views

Steve, you are right. Indeed, with -std=f2008 also gfortran throws an error for a module procedure within implicit none and flags it as a GNU extension. 

0 Kudos
Reply