- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, I see and ICE with the attached code, both versions (A) and (B).
$ ifort -c ice.f90
ice.f90(33): warning #6178: The return value of this FUNCTION has not been defined.
pure recursive function unpck(x) result(y)
-----------------------------------------^
ice.f90(45): catastrophic error: **Internal compiler error: internal abort** 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 ice.f90 (code 1)
$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0 Build 20150407
module m implicit none public :: t_base, unpck private type, abstract :: t_base contains private generic, public :: operator(+) => add procedure(i_add), pass(x), deferred :: add end type t_base type, extends(t_base) :: t_cont class(t_base), allocatable :: f contains procedure, pass(x) :: add => cont_add end type t_cont abstract interface elemental function i_add(x,y) result(z) import :: t_base, t_cont implicit none class(t_base), intent(in) :: x, y type(t_cont) :: z end function i_add end interface contains pure recursive function unpck(x) result(y) class(t_base), intent(in) :: x class(t_base), allocatable :: y end function unpck elemental function cont_add(x,y) result(z) class(t_cont), intent(in) :: x class(t_base), intent(in) :: y type(t_cont) :: z ! Both these lines produce an ICE z = unpck(x) + unpck(y) ! (A) !allocate( z%f , source=unpck(x)+unpck(y) ) ! (B) end function cont_add end module m
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for reporting this internal error. I will look into this and reply again soon.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
While it's true that an ICE implies some problem within the compiler and that compiler developers, especially at Intel, would want all those errors reported and resolved, the part about "valid code" is unclear. It seems to me the offending section in the code as shown boils down pretty much to the following which is invalid per the Fortran standard:
program p implicit none type, abstract :: t_base end type t_base type, extends(t_base) :: t_cont class(t_base), allocatable :: f end type t_cont class(t_base), allocatable :: a type(t_cont) :: b b = a stop end program p
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortranFan wrote:
It seems to me the offending section in the code as shown boils down pretty much to the following which is invalid per the Fortran standard:
Maybe I am overlooking something, otherwise I think the types are correct:
z = unpck(x) + unpck(y) ! now abusing a little the syntax highlight mechanism... class(t_base) :: unpck(x), unpck(y) type(t_cont) :: returned by add( t_base , t_base ) ! which is fine with type(t_cont) :: z
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MR wrote:
Quote:
FortranFan wrote:
It seems to me the offending section in the code as shown boils down pretty much to the following which is invalid per the Fortran standard:
Maybe I am overlooking something, otherwise I think the types are correct:
z = unpck(x) + unpck(y) ! now abusing a little the syntax highlight mechanism... class(t_base) :: unpck(x), unpck(y) type(t_cont) :: returned by add( t_base , t_base ) ! which is fine with type(t_cont) :: z
You are doing the addition within your binding for the add operator itself - the definitions seem to be going in circles.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I reported the internal error to Development (see internal tracking id below) and will update the post regarding that as I hear back.
While investigating the internal error I ran into the error #6197 that also occurs with FortranFan’s boiled down example. I’m waiting for help from Development to better understand the issue. There are other reports related to that error being invalid that may or may not be at play.
FYI - gfortran 5.1 suffers an internal error for (B) and successfully compiles (A).
(Internal tracking id: DPD200374211)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kevin Davis (Intel) wrote:
I reported the internal error to Development (see internal tracking id below) and will update the post regarding that as I hear back.
OK, thank you.
Kevin Davis (Intel) wrote:
While investigating the internal error I ran into the error #6197 that also occurs with FortranFan’s boiled down example.
I think FortranFan’s boiled down example was intended to be an invalid case, and I think that ifort correctly flags it as such:
ff.f90(15): error #6197: An assignment of different structure types is invalid.
The code that I posted, which produces the ICE, is valid, as far as I can tell, since the types involved in the assignment are correct.
Kevin Davis (Intel) wrote:
FYI - gfortran 5.1 suffers an internal error for (B) and successfully compiles (A).
Yes, I have reported it as Bug 67044.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page