Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29249 Discussions

polymorphic - catastrophic error: **Internal compiler error: internal abort**

Thomas_H_8
Beginner
1,334 Views

Hi,

thomas@cluster:~$ uname -a
Linux cluster 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
thomas@cluster:~$ ifort --version
ifort (IFORT) 12.0.4 20110427
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

thomas@cluster:~$ ifort  test.f90
test.f90(23): 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 test.f90 (code 1)

module BaseModule
  implicit none

  type base
    contains
    procedure :: func
  end type

  contains

  subroutine func(this)
  class(base) :: this
  end subroutine
end module

program test
  use BaseModule
  implicit none

  type(base) :: var

  open(var%func)
end

This happens after i change the variable func to a subroutine and don't update the code in the main program.

Can someone reproduce this error?

Regards

Thomas Huxhorn

0 Kudos
9 Replies
TimP
Honored Contributor III
1,334 Views
Yes, the internal error comes up also with our early release of ifort 13.0.079 for Intel64. So you would be welcome to file an issue on your premier.intel.com account, if you don't want to wait and see if this is picked up after our holiday tomorrow.
0 Kudos
Heinz_B_Intel
Employee
1,334 Views
Hello Thomas I will report the problem to compiler engineering and will keep ypu posted about any progress in fixing the issue.
0 Kudos
Thomas_H_8
Beginner
1,334 Views
Thank you very much.
0 Kudos
Heinz_B_Intel
Employee
1,334 Views
I submitted the issue to the engineering bug tracking system: Case number is DPD200235931. As Tim mentioned already, the soon to be released compiler version 13.0 shows the problem too. The failure happens in the front-end when parsing the derived type component in the OPEN statement. As a temporary workaround, you might try to avoid this construct until the bug will be fixed Heinz
0 Kudos
Heinz_B_Intel
Employee
1,334 Views
thanks for the reproducer. I will look into it and will report the problem to engineering
0 Kudos
Thomas_H_8
Beginner
1,334 Views
Here is the next one. Two classes. Both overwrites procedure open() with differen names and type signatur. Class ext derive from class base. If you call open() twice, the compiler crash or hangs. If you call open only once all is fine. Same compiler and machine. I attach the example code as file. Thanks for your help
0 Kudos
Heinz_B_Intel
Employee
1,334 Views
I have tested the sample application (example2) using the same compiler version 12.0 Update 4 you used and confirm the issue you report. However both, the latet 12.1 compiler ( 12.1 Update 11) and the just released compiler 13.0 compile the code fine. Thus please update to a newer compiler version to avoid this problem.
0 Kudos
Thomas_H_8
Beginner
1,334 Views
Thank you for the test! I'll update to a new version.
0 Kudos
Heinz_B_Intel
Employee
1,334 Views

The problem is fixed by the latest compiler release available from registrationcenter.intel.com ( download package l_fcompxe_2013.2.146 ). I will mark this thread as closed

0 Kudos
Reply