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

Catostrophic error: **Internal compiler error: internal abort** ifort v. 12.1.4 20120410

losalamos
Beginner
408 Views
We have an important code that has been unable to compile with the Intel Fortran compiler for Linux since version 10. We just tried the latest release and it, too, fails to compile. The reproducer code is given below but here is the error message:
$ ifort --version
ifort (IFORT) 12.1.4 20120410
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
$ ifort -c -fp-model strict -I . reproducer.F
0_12459
: 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 reproducer.F (code 1)
Here is the code that causes this error:
$ cat reproducer.F
FUNCTION EOS_REAL (X, shift, bnd, dim)
implicit none
include "param.h"
integer(kb) :: shift, dim
real(kb_r) :: bnd
real(kb_r) :: eos_real(0:mx,0:my,0:mz)
real(kb_r) :: X(0:mx,0:my,0:mz)
integer(kb) :: i,j,k, my_id
eos_real = eoshift(X, SHIFT=shift, BOUNDARY=bnd, DIM=1)
end function eos_real
FUNCTION EOS_LOG (X, shift, bnd, dim)
include "param.h"
integer(kb) :: shift, dim
logical(kb) :: bnd
logical(kb) :: eos_log(0:mx,0:my,0:mz)
logical(kb) :: X(0:mx,0:my,0:mz)
integer(kb) :: i,j,k
eos_log = eoshift(X, SHIFT=shift, BOUNDARY=bnd, DIM=1)
end function eos_log
$cat param.h
include "kind.h"
integer(kb) nx, ny, nz
integer(kb) mx, my, mz
integer(kb) nc, nv
integer(kb) nmat, mmat
integer(kb) nstr, mstr
integer(kb) nmts, mmts
integer(kb) nfrc, mfrc
integer(kb) ntm, mtm
integer(kb) nemm, memm
integer(kb) nprog, mprog
integer(kb) ndelq, mdelq
integer(kb) nmsff, mmsff
integer(kb) ncrs, mcrs
integer(kb) ndsd, mdsd
integer(kb) ndsdjwl, mdsdjwl
common /param/ nx, ny, nz,
& mx, my, mz,
& nc, nv,
& nmat, mmat,
& nstr, mstr,
& nmts, mmts,
& nfrc, mfrc,
& ntm, mtm,
& nemm, memm,
& nprog, mprog,
& ndelq, mdelq,
& nmsff, mmsff,
& ndsd, mdsd,
& ndsdjwl, mdsdjwl,
& ncrs, mcrs
integer(kb) nx_m1, ny_m1, nz_m1
integer(kb) mx_m1, my_m1, mz_m1
common /param_m1/ nx_m1, ny_m1, nz_m1,
& mx_m1, my_m1, mz_m1
$cat kind.h
integer, parameter :: kb_r = 4 ! single precision
integer, parameter :: kb = 4 ! single precision
integer, parameter :: kb4 = 4 ! single precision
integer, parameter :: kb8 = 8 ! double precision
This could be related to this problem (http://software.intel.com/en-us/forums/showthread.php?t=102565) for which in January was stated it was fixed in a future release. Any idea when that would appear?
This is a critical bug for us. Thanks.
-david
0 Kudos
3 Replies
Steven_L_Intel1
Employee
408 Views
I can reproduce the problem, but only if -fp-model strict is used. It does appear to be fixed in our next major release, scheduled for later this year. Can you avoid using -fp-model strict when compiling this source?
0 Kudos
losalamos
Beginner
408 Views
Unfortunately, no, we cannot remove the -fp-model strict requirement. The sensative nature of the code and its results are something I cann't bring up, but suffice it to say that it is of extreme significance to the Department of Energy's mission. :-/
0 Kudos
Steven_L_Intel1
Employee
408 Views
Perhaps you have access to our beta of the next version? If not, let me know.
0 Kudos
Reply