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

ifort error #8032

stortignauz
Beginner
784 Views
Dear all,

I'm experiencing a compile error with ifort version 11.0 build 20081105 on a Core2 laptop / Fedora10,
I suspect it is a bug.

when I compile a fortran90 module I get this error:
bator_lectures_mod.F90(994): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [YOMHOOK^DR_HOOK_DEFAULT]
IF (LHOOK) CALL DR_HOOK('BATOR_ELIM',1,ZHOOK_HANDLE)
----------------^

Then, looking into the module YOMHOOK which causes the error I find:

[...]
INTERFACE DR_HOOK
MODULE PROCEDURE &
DR_HOOK_DEFAULT, &
DR_HOOK_FILE, &
DR_HOOK_SIZE, &
DR_HOOK_FILE_SIZE, &
DR_HOOK_MULTI_DEFAULT, &
DR_HOOK_MULTI_FILE, &
DR_HOOK_MULTI_SIZE, &
DR_HOOK_MULTI_FILE_SIZE
END INTERFACE
[...]

And the relevant part is

SUBROUTINE DR_HOOK_DEFAULT(CDNAME,KSWITCH,PKEY)
CHARACTER(LEN=*), INTENT(IN) :: CDNAME
INTEGER(KIND=JPIM), INTENT(IN) :: KSWITCH
REAL(KIND=JPRB), INTENT(INOUT) :: PKEY
CALL DR_HOOK_UTIL(CDNAME,KSWITCH,PKEY,'',0)
END SUBROUTINE DR_HOOK_DEFAULT

SUBROUTINE DR_HOOK_MULTI_DEFAULT(CDNAME,KSWITCH,PKEY)
CHARACTER(LEN=*), INTENT(IN) :: CDNAME
INTEGER(KIND=JPIM), INTENT(IN) :: KSWITCH
REAL(KIND=JPRB), INTENT(INOUT) :: PKEY(:)
CALL DR_HOOK_UTIL_MULTI(CDNAME,KSWITCH,PKEY,SIZE(PKEY),'',0)
END SUBROUTINE DR_HOOK_MULTI_DEFAULT

To me it seems that ifort is not able to correclty address the procedure
to one of the two subroutines (DR_HOOK_DEFAULT vs DR_HOOK_MULTI_DEFAULT)
if the only difference is that one argument is a REAL in the first case
or a REAL array of undefined length.

Note that the code compiles on many platforms I tested (Linux/pgi, IBM/xlf at least)

Do you have any idea??? Have you experienced something similar???

Of course the problem is easy to remove in the code, but I'd like to know
why ifort fails,

Thanks in advance for your help,

Regards

Andrea

0 Kudos
4 Replies
Kevin_D_Intel
Employee
784 Views

It appears ifort failed to distinguish the interfaces related to PKEY.

I do not know if this is a known issue but can create a mock up to test this. Others may know immediately.
0 Kudos
stortignauz
Beginner
784 Views

It appears ifort failed to distinguish the interfaces related to PKEY.

I do not know if this is a known issue but can create a mock up to test this. Others may know immediately.

Hi,

I've tried to reproduce the situation in a simpler context, and I can correctly compile and run
with multiple procedures and unknown array length, so I believe the problem is not the one
I was thinking,

Regards, and thanks a lot anyway for the quick reply

Andrea
0 Kudos
Kevin_D_Intel
Employee
784 Views

An instance of the incorrect issuance of error #8032 was reported with the compiler build you noted (update 11.0.074). That issue is fixed in the latest 11.0.081 update.

That case involved generic INTERFACE declarations appearing in separate modules which I do not see in your case; however, your case may be related. At your convenience, I encourage that you download the 11.0.081 update and give it a try. You can have both 11.0.074 and 11.0.081 installed simultaneously.
0 Kudos
stortignauz
Beginner
784 Views

An instance of the incorrect issuance of error #8032 was reported with the compiler build you noted (update 11.0.074). That issue is fixed in the latest 11.0.081 update.

That case involved generic INTERFACE declarations appearing in separate modules which I do not see in your case; however, your case may be related. At your convenience, I encourage that you download the 11.0.081 update and give it a try. You can have both 11.0.074 and 11.0.081 installed simultaneously.

Hello again Kevin,

thanks a lot for your support and help,

to me the case you pointed out seems exactly my problem:
the only difference I have noted between my simplified test and the one causing problem
is exactly that the module containing the interface
is called in the module causing compiling error both in the preamble (before the CONTAINS statement)
and within the subroutine, so it should be the case you mentioned... since there exists a conflict/double
call to the module.

Thanks again for your suggestions

Andrea
0 Kudos
Reply