catastrophic error with ifort 11.1.064 on Linux (repost)

[Hans_Peschke]

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:

[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

[Kevin_D_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)

(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).

[Hans_Peschke]

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?

[Kevin_D_Intel]

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.

[Hans_Peschke]

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

[Hans_Peschke]

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

[Kevin_D_Intel]

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.

[Hans_Peschke]

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.

Thanks for the latest news.

maybe this is related to these errors.

[Hans_Peschke]

Hi,
are there any news on this issue?

Best regards

Hans

[Steven_L_Intel1]

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.

[Kevin_D_Intel]

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.

[Hans_Peschke]

Thank you Steve, Kevin and the development team for the great news. Im looking forward to the new release :)

Hans

[Kevin_D_Intel]

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.