topic Intel Composer stumbles over overlay in Intel® Fortran Compiler

Intel Composer stumbles over overlay

jr_reuter — Tue, 07 Dec 2010 16:09:54 GMT

The following code is not correctly compiled by the Intel Fortran Compiler with the following version:
Intel Fortran Compiler XE for applications running on IA-32, Version 12.0.1.107 Build 20101116
The error message is the following:
processes.f90(94): error #7096: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [STRFUN^BEAMS^BEAM_ASSIGN]
use strfun
------^
processes.f90(93): error #7096: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [BEAMS^BEAM_ASSIGN]
use beams
------^
compilation aborted for processes.f90 (code 1)

Note that all other compilers at my hand do compile the code
(NAG, gfortran, g95, Portland)
Here is the code:

! Putting this in the same module beams makes the bug vanish

module interactions

implicit none
private

public :: interaction_t

type :: interaction_t
private
integer :: tag = 0
end type interaction_t

end module interactions

!!!!!!!!!!

module beams

use interactions

implicit none
private

public :: beam_t
public :: assignment(=)

type :: beam_t
private
type(interaction_t) :: int
end type beam_t

interface assignment(=)
module procedure beam_assign
end interface

contains

subroutine beam_assign (beam_out, beam_in)
type(beam_t), intent(out) :: beam_out
type(beam_t), intent(in) :: beam_in
beam_out%int = beam_in%int
end subroutine beam_assign

end module beams

!!!!!!!!!!

module strfun

use beams

implicit none
private

public :: strfun_chain_t
!!! Commenting out this line triggers the error going away!!!
public :: assignment(=)

type :: strfun_t
private
integer :: type = 0
end type strfun_t

type :: strfun_chain_t
private
type(beam_t) :: beam
type(strfun_t), dimension(:), allocatable :: strfun
end type strfun_chain_t

!!! THIS PART OF THE CODE IS NOT NEEDED TO REPRODUCE THE BUG
!!!
!!! interface assignment(=)
!!! module procedure strfun_chain_assign
!!! end interface
!!!
!!!contains
!!!
!!! subroutine strfun_chain_assign (sfchain_out, sfchain_in)
!!! type(strfun_chain_t), intent(out) :: sfchain_out
!!! type(strfun_chain_t), intent(in) :: sfchain_in
!!! sfchain_out%beam = sfchain_in%beam
!!! end subroutine strfun_chain_assign

end module strfun

!!!!!!!!!!

module processes

use beams
use strfun

implicit none
private

!!! Commenting out these lines triggers the error going away!!!

type :: md5sum_grids_t
character(32) :: beams = ""
end type md5sum_grids_t

end module processes

Intel Composer stumbles over overlay

Kevin_D_Intel — Tue, 07 Dec 2010 16:48:43 GMT

Thank you for notifying us about this. I reproduced the errors andwill submit to Develpment and update this post as I learn more.

(Internal tracking id: DPD200164645)

(Resolution Update on 05/17/2011): This defect is fixed in the Intel Fortran Composer XE 2011 Update 4 (2011.4.191 - Linux)

Intel Composer stumbles over overlay

jr_reuter — Tue, 28 Dec 2010 14:25:03 GMT

So how long does it normally take to assign such a bug and fix it for the Intel Compiler?
From gfortran and NAG that is usually order of days, for Portland it is order a few weeks. For Intel I reported
this error (actually tried to report this error) during the several updates of the 11.0 and 11.1 compilers
for more than a year now (more like one and a half years). And now the post on the Forum is also
already 3 weeks old. Just to be curious...

Time frame for bug fixes

mecej4 — Tue, 28 Dec 2010 15:30:02 GMT

You can see for yourself by browsing the compiler forums.

My observations:

i) workarounds, if possible, are posted anywhere from within a few hours to a few days.

ii) most bugs are fixed and the bug-fixes are rolled into the next update; updates come out at two to three month intervals.

iii) some bugs are troublesome in that changing the compiler to fix those bugs would break other parts of the compiler; some other bugs are just hard to fix; then there are bugs that may disappear on their own when a major revision of the compiler is made. The bugs in these categories take anywhere from two or three updates to the next major release.

Time frame for bug fixes

Kevin_D_Intel — Tue, 28 Dec 2010 16:25:54 GMT

My apologies for the delay. Typically, reproducing and reporting to Development usually is just a matter of a day or two. There were extenuating circumstances that delayed my getting that done for this case and a couple of others. I am catching up on them now.

Providing a fix is gated by the time Developers require to investigate, fix and test, and then availability is further based on release schedules. We provide updates on availability of a fix and any work-around as we learn them.

As for this error, I do not have information about what you may have reported earlier, but the issue does not exist with 11.1 Build 20101201 (Package ID: l_cprof_p_11.1.075). The code compiles as written. You also already noted a possible work-around of including module interactions inside module beam, which I confirmed works with the XE 2011 release.

This has been sent to Development. I noted the internal tracking id in my earlier post and will post updates as I learn more.

Time frame for bug fixes

jr_reuter — Tue, 18 Jan 2011 13:53:52 GMT

Ok, you are going to an older version of the compiler now. I have made the experience that this error is there
and was always there. Just when the compiler version was updated the error moved to a different part of the code. What I could do (and I offered that several times) to send you our complete code (which is however roughly 50,000 to 60,000 lines of Fortran code and check with the different compiler versions.

Time frame for bug fixes

Kevin_D_Intel — Mon, 24 Jan 2011 10:50:49 GMT

Sorry for the delay. I reviewed the history of your Premier issues submittedand found for the last one submitted in the Feb. 2010 that you attached your entire code. I assume that copy is no longer current. I did not see an instance of the error #7096 though.

If you want, please open another Premier issue to provide the current code to me and then I can check it against different compiler versions. You can request the issue be assigned to me. Alternatively, you can upload the gzipped-tar to this forum using a Private reply.

Development has not provided any further update regarding the error #7096 reported here. I will update on that when I learn more.

Time frame for bug fixes

jr_reuter — Tue, 25 Jan 2011 13:29:36 GMT

Ok, cool. For some reason I cannot open up any new premier support issues (maybe my support has run out, but I don't know. I open up a tarball for you. Let me prepare it and break it down to treatable blocks.

Time frame for bug fixes

jr_reuter — Tue, 25 Jan 2011 15:27:41 GMT

OMG, in preparing my code, I found out that the newest version 12.0.1 does have another ICE. Will open a separate issue for this.

Time frame for bug fixes

Kevin_D_Intel — Tue, 25 Jan 2011 17:34:30 GMT

I'm sorry to hear this. Your Premier account is still active so I'm not sure what you faced there. I'll watch for your updates about the tarball.