error #6404: This name does not have a type, and must have an explicit type - using function in subroutine

Question

I am using Fortran 90 and the Intel compiler. I am very confused using a function in a subroutine. My code is (I deleted everything unimportant):

program test
INTEGER     :: seed=5 
REAL        :: nor_ran_number1, nor_ran_number2
CALL Box_Muller_transform(seed,nor_ran_number1,nor_ran_number2)
end program test

double precision function grnd(SEED)
grnd=5
return
end

SUBROUTINE Box_Muller_transform (seed,nor_ran_number1,nor_ran_number2)
implicit none
INTEGER, INTENT(in) :: seed
REAL, INTENT(out)   :: nor_ran_number1, nor_ran_number2

    nor_ran_number1 = grnd(seed)
    nor_ran_number2 = grnd(seed)

end SUBROUTINE Box_Muller_transform

The compiler returns:

error #6404: This name does not have a type, and must have an explicit
type.   [GRND]
nor_ran_number1 = grnd(seed)
------------------^

I found this and understand that the function "grad" is not visible inside "Box_Muller_transform". However then I would expect the following code to produce the same error:

program test
INTEGER ::a=5, b
call sub(a,b)
write(*,*) b
end program 

SUBROUTINE sub(a,b)
INTEGER, INTENT(in)     ::a
INTEGER, INTENT(out)    ::b
b = fun(a)
end subroutine sub

function fun(a)
INTEGER     :: fun 
INTEGER     :: a
fun         = a*a
end function fun 

But this is working. I would be very happy if someone could point out the difference and explain the simplest way to solve this problem.

Answer 1

Functions must have their return value defined. Since you are using implicit none in your first example, the type of the return value of grnd must be defined explicitly:

SUBROUTINE Box_Muller_transform (seed,nor_ran_number1,nor_ran_number2)
implicit none
INTEGER, INTENT(in) :: seed
REAL, INTENT(out)   :: nor_ran_number1, nor_ran_number2
double precision    :: grnd

    nor_ran_number1 = grnd(seed)
    nor_ran_number2 = grnd(seed)

end SUBROUTINE Box_Muller_transform

In the second example, you have not specified implicit none in sub, therefore fun is assumed to be of (implicit) type real. The compiler seems to silently cast this to integer.