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

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

Thomas_H_8
Principiante
3.217 Visualizações

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 Respostas
TimP
Colaborador honorário III
3.217 Visualizações
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.
Heinz_B_Intel
Funcionário
3.217 Visualizações
Hello Thomas I will report the problem to compiler engineering and will keep ypu posted about any progress in fixing the issue.
Thomas_H_8
Principiante
3.217 Visualizações
Thank you very much.
Heinz_B_Intel
Funcionário
3.217 Visualizações
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
Heinz_B_Intel
Funcionário
3.217 Visualizações
thanks for the reproducer. I will look into it and will report the problem to engineering
Thomas_H_8
Principiante
3.217 Visualizações
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
Heinz_B_Intel
Funcionário
3.217 Visualizações
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.
Thomas_H_8
Principiante
3.217 Visualizações
Thank you for the test! I'll update to a new version.
Heinz_B_Intel
Funcionário
3.217 Visualizações

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

Responder