ICE with valid code

[MR]

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

[Kevin_D_Intel]

Thank you for reporting this internal error. I will look into this and reply again soon.

[FortranFan]

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

[MR]

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

[FortranFan]

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.

[Kevin_D_Intel]

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)

[MR]

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.