Catastrophic error while compiling large file

[ereisch]

Unfortunately, I cannot post the entire source file that leads to this error, but the diagnostic seems to include more details than usual, so I'm hoping the compiler developers will be able to locate the issue without the source.  If not, let me know and I'll try to generate a reproducer.

file.i: error #5270: Internal Compiler Error: symbol not a SYMTOK
Bad allocation strategy
file.i: catastrophic error: **Internal compiler error: abort signal raised** Please report this error.....

[ereisch]

ifort version 19.1.3.304

Compile line:

ifort -module ./.mod -warn noalignments -fpp -no-save-temps -extend-source 132 -assume nounderscore -gen-interfaces nosource -syntax-only -DWITH_MKL -I./.mod -m32 -I./text test.for

[Steve_Lionel]

Unfortunately, the message does not help identify the problem. First, try it with the 2021.1.2 oneAPI compiler (free). If it still fails, try to come up with a smaller reproducer. I have seen that message come up with issues related to host association.

You should also try gradually removing options to see if one of them triggers the issue - that is an additional help in locating the compiler bug (and a "catastrophic error" is always a compiler bug.)

[Ronald_G_Intel]

if it's a large, complex source with a lot of USE statements you should also try option

-qoverride-limits

[JohnNichols]

if(event == "catastrophic error" and type == "Fortran") then 
           RESULT = "is always a compiler bug.")
Elseif(event == "catastrophic error" and type == "Sandy Desert") then 
           RESULT = "refrigator is broken and the beer is hot.")

[ereisch]

Unfortunately, no.  If I change pretty much any compilable line in the file, the error disappears.  The bare minimum compiler flags that still generates the exception are:

ifort -fpp -extend-source 132 -gen-interfaces nosource -syntax-only -I/some/path file.for

 If I try compiling without generating an interface module file, it doesn't have issues.  If I insert a line after the variable definition section assigning a random variable a random value, it doesn't have issues.  If I remove any random line in the file, it doesn't have issues.  If I comment out any random line of code, it doesn't have issues.

[ereisch]

Unfortunately, also did not work.

[ereisch]

Sorry, the replies are inlining into the messages I'm clicking "Reply" on.  Ron's suggestion did not work.

[Ronald_G_Intel]

what version of the compiler do you use?

[ereisch]

ifort version 19.1.3.304

[mecej4]

Ereisch, the scanty evidence that you have given is, I think, simply insufficient for the compiler developers to attempt any fixing. By your own declaration, small changes to the code being compiled make the error disappear.

If I had written a large, complex, program with a tiny section that checked for an error and that section could have been called from dozens of diverse places, merely being told by one of my program users that the error message was displayed, without the program user telling me how to reproduce the error, I would not be able to do anything.

[jimdempseyatthecove]

>>If I try compiling without generating an interface module file, it doesn't have issues. If I insert a line after the variable definition section assigning a random variable a random value, it doesn't have issues. If I remove any random line in the file, it doesn't have issues. If I comment out any random line of code, it doesn't have issues.

I seem to recall similar issues in the past. In particular "If I insert a line after the variable definition section assigning a random variable a random value, it doesn't have issues" could be indicative that the prior 1st execution statement was ambiguous as to if it were an executable statement .OR. a statement function.

The statement function ambiguity (should it exist) may interact with interface checking.

Note, nothing inherently wrong with statement functions (other than being distasteful for newer Fortran programmers/committee members).

Removing/Commenting a random line would be indicative of something else (but this does not preclude an interaction with s.f.)

Does your program use INCLUDE and/or #include?

If so, assure that the included file ends with a line terminator.

Also, the compiler default optimization may enable IPO, add the flag to disable ipo.

Jim Dempsey

[Ronald_G_Intel]

as Jim suggested, add option  -O0

otherwise you get -O2 with a lot of optimizations turned on.