- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
due to the deletion of my former article, without any comment to me, here is the repost, in order to get clearence about it.
The following code results in an Catastrophic Error with ifort 11.1.064 on Ubuntu 9.10:
Hans Peschke
due to the deletion of my former article, without any comment to me, here is the repost, in order to get clearence about it.
The following code results in an Catastrophic Error with ifort 11.1.064 on Ubuntu 9.10:
[plain]$ ifort ifort_error_foo.f90 : catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for ifort_error_foo.f90 (code 3) [/plain]Code:
[plain]module ifort_error_foo implicit none abstract interface function iface_A() result(res) real, allocatable, dimension(:) :: res end function iface_A end interface type :: type_A procedure(iface_A), nopass, pointer :: fun end type type(type_A), dimension(1) :: funs contains subroutine initialize_funs() funs(1)%fun => funA end subroutine initialize_funs function funA() result(res) real, allocatable, dimension(:) :: res allocate(res(1)) res(1) = 0.0 end function funA end module ifort_error_foo program test ! use... implicit none write(*,*) 'works' end program test[/plain]Compiler output:
[plain]$ ifort ifort_error_foo.f90 : catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for ifort_error_foo.f90 (code 3) $[/plain]Thanks in advance
Hans Peschke
Link Copied
12 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Hans for notifying us about this internal error (again) and for the convenient reproducer. I don't know how/why your earlier post was deleted. The error is reproducible with newer development compilers also. I submitted to Development and will keep this thread updated as I learn more.
(Internal tracking id: DPD200148934)
(Resolution Update on 08/31/2010): This defect is fixed in the Intel Fortran Compiler Professional Edition 11.1 Update 7 (11.1.073 - Linux).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
Thank you Hans for notifying us about this internal error (again) and for the convenient reproducer. I don't know how/why your earlier post was deleted. The error is reproducible with newer development compilers also. I submitted to Development and will keep this thread updated as I learn more.
(Internal tracking id: DPD200148934)
Thank you Kevin.
I assume, that the next version is realeased in a few month's from now. Do you know an other possibility to iterate over procedures as workaround?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Hans Peschke
Thank you Kevin.
I assume, that the next version is realeased in a few month's from now. Do you know an other possibility to iterate over procedures as workaround?
Yes, what is referred to as 11.1 "Update 5" is tentatively scheduled for release in late January/early February 2010.
I haven't found a work around but will let you know if I learn of one. The segmentation fault occurs in relation to the declaration of funs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Hans Peschke
Do you know an other possibility to iterate over procedures as workaround?
I've done some (basic) testing.
First for iteration over procedures you have do define a type, with a procedure component:
[plain]type :: fun procedure(fun), pointer, nopass :: f character(len=2) :: name end type[/plain]But for the signature fun of the procedure-component f, there are at least two possibilities:
- fun is an abstract interface
- fun is an implemented procedure (here: pure function with one formal-argument having the same type as the result)
Next, you have to define your array and have to initialize it:
[plain]integer, parameter :: num_funs = 4 type(fun), dimension(num_funs) :: funs contains subroutine init_funs() funs(1)%f => f1 funs(1)%n = 'f1' funs(2)%f => f2 ... end subroutine init_funs [/plain]In the end, the iteration works straight forward:
[plain]program test use iterate_over_proc implicit none integer :: i call init_funs() do i=1, num_funs write(*,*) funs(i)%n, ' : ', funs(i)%f(1.0) end do end program test[/plain]So far so good.
The problem depends on the result-type, of the pure function:
If the result-type (and here the formal-argument-type) is
- intrinsic (e.g. real, integer), then there are no problems with both versions of defining fun.
- array of e.g. real's, then we get an catastrophic error with both versions of defining fun.
- is a derived-type with intrinsic components, then it works with both versions of defining fun.
- is a derived-type with an array component of an intrinsic type, then it works too :)
Conclusion:
- Iteration over procedures works and the encapsulation of an array in an derived-type seems to be an workaround for me.
- There are a lot of other combinations, for example: the functions take an procedure as argument, ...
Best regards and Happy New Year!
Hans Peschke
P.S. the attachement contains the code I used
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Hans Peschke
I've done some (basic) testing.
...
The problem depends on the result-type, of the pure function:
If the result-type (and here the formal-argument-type) is
- intrinsic (e.g. real, integer), then there are no problems with both versions of defining fun.
- array of e.g. real's, then we get an catastrophic error with both versions of defining fun.
- is a derived-type with intrinsic components, then it works with both versions of defining fun.
- is a derived-type with an array component of an intrinsic type, then it works too :)
Another workaround without derived-type encapsulating the array in some cases is: Not define the array-result-type as allocatable, but with constant size:
[plain]abstract interface pure function fi_iface(x) result(res) real, intent(in) :: x real, dimension(2) :: res end function fi_iface end interface[/plain]or depending on an other argument:
[plain]abstract interface pure function fi_iface(x, n) result(res) real, intent(in) :: x integer, intent(in) :: n real, dimension(n) :: res end function fi_iface end interface [/plain](this works also if fun (look up) is an implemented procedure and not an abstract interface)
Best regards
Hans Peschke
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I appreciate the updates Hans. Those suggested alternatives may very well help others too. I also passed those along to Development.
The news from Development is not so good. They said the original sample actually exposes more than one problem. There is a problem when declaring funs is in a module (rather than a routine). Other problems relating to funs being an array (vs scalar), and problems related to funA returning an allocatable array. They are beginning to address all these but it may take a couple of updates to roll out all the related fixes. There is not a convenient work around with the number of problems at play.
I'm sorry I dont have better news. I'll update the thread as I learn more.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
The news from Development is not so good. They said the original sample actually exposes more than one problem. There is a problem when declaring funs is in a module (rather than a routine). Other problems relating to funs being an array (vs scalar), and problems related to funA returning an allocatable array. They are beginning to address all these but it may take a couple of updates to roll out all the related fixes. There is not a convenient work around with the number of problems at play.
maybe this is related to these errors.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
are there any news on this issue?
Best regards
Hans
are there any news on this issue?
Best regards
Hans
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From what I can see, the last of the fixes needed to make your program build was recently completed - that should appear in Update 7, scheduled for August.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hans,
Your program provoked a number of defects, all of which Development hasnow fixed as Steve indicated earlier. I verified your test casecompiles successfullyusingourlatest developmentcompiler whichfurther confirms all associated fixes will appear in the next 11.1 Update 7.
I will let you know when that update becomes available.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Steve, Kevin and the development team for the great news. Im looking forward to the new release :)
Hans
Hans
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hans,
The 11.1 Update 7 (11.1.073 - Linux) containing this fix is now available from the Intel Registration Center: https://registrationcenter.intel.com
Our apologies for the time to repair all that your program exposed. We appreciate your patience and reporting the issues.
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