Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

MKL_GET_MAX_THREADS() in Fortran 90/95

dbacchus
Beginner
1,193 Views

MKL version: 10.1.1.022
IFC version: 11.1.051
Platforms: linux x64, win7 x64

The compiler complains about MKL_GET_MAX_THREADS() when being called
MKL_MT=MKL_GET_MAX_THREADS()
("This name does not have a type, and must have an explicit type. [MKL_GET_MAX_THREADS]"

In the same code the subroutines, e.g. call MKL_SET_NUM_THREADS(N), are being executed just fine.

What's the proper F95 interface to MKL_GET_MAX_THREADS() function? Is there a way not to provide the include path (which isan artifact of F77)?
I just think it would be much more convenient to make a module like omp_lib for MKL functions.
Thanks.

0 Kudos
5 Replies
Vladimir_Koldakov__I
New Contributor III
1,193 Views

Hi,

Fortran95 standard requires an explicit interface in most cases. You can find the full list in the Intel Fortran document "Intel Fortran Compiler User and Reference Guides" => "Language Reference" => "Program Units and Procedures" => "Procedure Interfaces" => "Determining When Procedures Require Explicit Interfaces".

I believe your main program includes "implicit none" statement. Without this statement a program should be compiled:


!implicit none

integer nth

nth = mkl_foo()

print *,nth, mkl_foo()

end

integer function mkl_foo

mkl_foo = 7

end function mkl_foo

$ ifort explicit.f90 && ./explicit

7 7

Note: in this case mkl_foo is interpreted according to the (Fortran77) implicit rules. So, if name of the function is dmkl_foo, then:

$ ifort explicit.f90 && ./explicit

7 7.000000

MKL really does not provide interfaces for the service functions. So you may either omit "implicit none" statement or add interface for required functions, like:

implicit none

interface

integer function mkl_foo()

end function mkl_foo

end interface

integer nth

nth = mkl_foo()

print *,nth, mkl_foo()

end

integer function mkl_foo

mkl_foo = 7

end function mkl_foo

$ ifort explicit.f90 && ./explicit

7 7

Thanks,

Vladimir

0 Kudos
dbacchus
Beginner
1,193 Views
Thanks, Vladimir!
I'm curious though, in which category below does MKL_GET_MAX_THREADS() fall and MKL_SET_NUM_THREADS does not?I don't quite understand why the former needs theinterface, while the latter doesn't.Also, I have a similar question regarding MKL_FREE_BUFFERS which has no arguments.

Quote (Intel Fortran Compiler User and Reference Guide):

A procedure must have an explicit interface in the following cases:

  • If the procedure has any of the following:

    • A dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE, or VOLATILE attribute

    • A dummy argument that is an assumed-shape array

    • A result that is an array, or a pointer, or is allocatable (functions only)

    • A result whose length is neither assumed nor a constant (character functions only)

  • If a reference to the procedure appears as follows:

    • With an argument keyword

    • As a reference by its generic name

    • As a defined assignment (subroutines only)

    • In an expression as a defined operator (functions only)

    • In a context that requires it to be pure

  • If the procedure is elemental


P.S. I'm totally lost. I've implemented the interface for MKL_GET_MAX_THREADS()
[plain]implicit none

interface
 integer function mkl_get_max_threads()
 end function mkl_get_max_threads
end interface
[/plain]

and the code compiles and works fine.
Now, I'm trying to do the samewith MKL_MEM_STAT()

[cpp]INTERFACE
integer*8 function MKL_MEM_STAT(AllocatedBuffers )
integer*4 AllocatedBuffers 
END
END INTERFACE[/cpp]


and the linker produces an error (unresolved...). Why?

0 Kudos
dbacchus
Beginner
1,193 Views
I firgured out MKL_MEM_STAT problem. Apparently, it was only defined in MKL 10.2, in previous versions (10.1) it was called MKL_MEMSTAT. Now, MKL 10.2.2.025 has a bug that makes ARPACK's dseupd return incorrect eigenvectors. Therefore, I had to use MKL 10.1, for which MKL_MEM_STAT was not (yet) defined. MKL_MEMSTAT works fine though for MKL 10.1...
Of course, MKL_FREE_BUFFERS has the same problem: in MKL 10.1 it is called MKL_FREEBUFFERS...
0 Kudos
Gennady_F_Intel
Moderator
1,193 Views
Quoting - dbacchus
I firgured out MKL_MEM_STAT problem. Apparently, it was only defined in MKL 10.2, in previous versions (10.1) it was called MKL_MEMSTAT. Now, MKL 10.2.2.025 has a bug that makes ARPACK's dseupd return incorrect eigenvectors. Therefore, I had to use MKL 10.1, for which MKL_MEM_STAT was not (yet) defined. MKL_MEMSTAT works fine though for MKL 10.1...
Of course, MKL_FREE_BUFFERS has the same problem: in MKL 10.1 it is called MKL_FREEBUFFERS...

MKL_MemStat is an obsolete name for the MKL_Mem_Stat function that is referenced in the library for back compatibility purposes but is deprecated and subject to removal in subsequent releases.
The similar situation happens with some others service routines.
But it's not clear why the linker produces the error when you use obsolete name from 10.1 while linked with 10.2 .
We will check it. Thanks for the report.
--Gennady
0 Kudos
dbacchus
Beginner
1,193 Views

MKL_MemStat is an obsolete name for the MKL_Mem_Stat function that is referenced in the library for back compatibility purposes but is deprecated and subject to removal in subsequent releases.
The similar situation happens with some others service routines.
But it's not clear why the linker produces the error when you use obsolete name from 10.1 while linked with 10.2 .
We will check it. Thanks for the report.
--Gennady

Actually, I was linking with 10.1 (I couldn't use 10.2 due to the reason described above).
I will make sure to update the code to new naming conventions (MKL_MEMSTAT => MKL_MEM_STAT, etc) once the eigenvector problem with 10.2 is fixed. Thanks!
0 Kudos
Reply