Catastrophic Compiler error IFC 2017

[Brian_A_]

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

[TimP]

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.
 

[Brian_A_]

I am installing the update now.  I just got a email with the update link.

[Steven_L_Intel1]

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.

[Brian_A_]

Still getting the catastrophic error

IFC Version 17.0.1.143 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)

[Steven_L_Intel1]

Ok, now we need the source file(s). A snippet is not sufficient.

[Lorri_M_Intel]

Is that really the command?  It looks like a combination of Windows and Linux.  Are you building for Intel Xeon Phi maybe?

                       --Lorri

[Brian_A_]

Here are links to the two files used for compiling.

First one calls the second one.

http://www.relap.com/files/makeri

http://www.relap.com/files/makerip

[mecej4]

The two files in #8 are pieces of Make scripts. What is needed, however, is the file with the source code that causes the compiler error.

[Brian_A_]

Ok here is the file that the error is occuring in.

http://www.relap.com/files/fcph.ff

Line 51 is supposedly where the error is

[mecej4]

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 17.0.1.143 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.

[Brian_A_]

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_]

Any additional information on this would be great.

[mecej4]

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.

[Brian_A_]

http://relap.com/files/fcph.for

Ok here is the link to the pre-processed file.

Line 63 is where the error is supposedly from.

[mecej4]

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: 

1. In the declaration of the statement function cp, change the dummy argument fotmtl to something different from the name of the third dummy argument of the function fcph, OR
2. Change the "2.d0" in the last line of the statement function to "2.0" or "2e0".

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.

[Steven_L_Intel1]

Thanks to mecej4 for isolating the issue. Escalated as DPD200415852.