Quantcast
Channel: Intel® Software - Intel® Fortran Compiler for Linux* and macOS*
Viewing all articles
Browse latest Browse all 2746

Order of declaration statements with and without implicit typing

$
0
0

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.

 


Viewing all articles
Browse latest Browse all 2746

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>