I am getting a catastrophic compiler error using the IFC 2017 version. Have never encountered this before. I have been compiling the same code for years using IFC. The 2015 version never gave this error.
matpro\fcph.for(63): 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 matpro\fcph.for (code 1)
data c1u ,c2u ,c3u ,thu ,edu / 296.7d0, 2.43d-02, 8.745d07, + 535.285d0, 1.577d05 / data c1pu,c2pu,c3pu,thpu,edpu/ 347.4d0, 3.95d-04, 3.860d07, + 571.0d0, 1.967d05 / data c1gd,c2gd,c3gd,thgd,edgd/ 315.86d0, 4.044d-02 , 0.0d0, + 348.0d0, 0.0d0/ cp(c1,c2,c3,th,ed,t,fotmtl) = # c1*(th**2)*exp(th/t)/((t**2)*((exp(th/t)-1.d0)**2))+c2*t+ Line 63 # (fotmtl/2.d0)*(c3*ed/(8.314d0*(t**2)))*exp(-ed/(8.314d0*t)) t = ftemp r = facmot tm = ftmelt fcomp = comp/100.0d0 fcpmol = 503.0d0 c fcpmol = specific heat
If you are seeing a failure with the 2017 update 1 (why do people say "the" version when there are more than 1?) you might better follow the instructions. as you don't appear to have provided sufficient information.
If you still see a problem with Update 1, please provide a complete compilable source that reproduces the problem and tell us what command options you use for the compile.
Still getting the catastrophic error
IFC Version 184.108.40.206 Build 20161005
Here is the command line for the compiler
ifort -nologo -c -auto -Qansi_alias- -pad_source -traceback -fltconsistency -fpconstant -nogen-interfaces -module:o -Io -Ienvrl -Imatpro -Irelap -Iscdap -Igraphics -object:envrl\aaetit.o (file to be compiled goes here)
The -l.... options (those that have lower-case L as the leading character) that you showed in #5 are superfluous when -c is also specified, because -c says 'compile, don't link' and all the -l options apply to linking.
On Windows, using the command
ifort /c /Qansi_alias /Qpad_source /traceback /fltconsistency /fpconstant /nogen-interfaces /module:o fcph.f
I found that the 220.127.116.11 compiler produced the corresponding .OBJ file with no error messages or ICE.
The line that you gave (Line 63) in #1 as the problem line is part of the declaration of an ASF (Arithmetic Statement Function, which is an "obsolescent" feature of the language -- F2008, B.2.4). The statement function declaration in the file that you linked to in #10 is in lines 49-51, so we are probably looking at different versions of the source file.
All of my sources files,.ff, go through a pre-processor and are converted to .for., so the #1 comment is the .for file and the #10 comment is the .ff file. That is why the difference in line numbers.
Brian A. wrote:
Any additional information on this would be great.
An ICE (internal compiler error) is a generic name for all compiler errors that are detected at a stage when it is too late to issue a meaningful diagnosis of the error and take steps to recover from the error. I think that it is next to impossible to investigate the causes of such generic errors without having at least one source code that provokes the compiler into aborting with an ICE. You have provided only snippets of code and a link to a file which, when run through a preprocessor unknown to us, generates source code that causes the compiler to abort with an ICE.
Please provide the source code that you actually run the compiler on, i.e., the output of the preprocessor. Your makefile probably saves the preprocessor output to a temporary Fortran source file, runs the compiler on it, and then deletes the temporary file. You have to do either (i) intercept the make process prior to the deletion of the temporary file and give us that source file, or (ii) provide the preprocessor and instructions (options, command line, etc.) to run the preprocessor on a .ff file and produce a .f (or .f90) file.
Thanks, that completes the picture. I have prepared a simplified reproducer and reported the bug at https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/702945 .
Here are two versions of a simple work-around:
I note in passing that there are various instances of double precision constants in expressions containing single precision variables. Single precision variables are initialized with double precision constants in the DATA statement. The compiler can handle these, but the presence of "Dnn" suffixes may mislead a reader into believing that the entire calculation is being made in double precision or that double precision is required.