- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page