ICE: specifcation exception signal raised

ICE: specifcation exception signal raised

Hi: I'm compiling a rather large 3rd party application with ifort 13.1.1 20130313 and ifort is failing on several files with the message:

catastrophic error: **Internal compiler error: specification exception signal raised** 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.

Before I dive into the source to create a simplified case, I wanted to know if "specification exception" meant something specific (hah!) that could help me narrow my search.


14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

If you are able to attach one of those files and the compile command on the forum or to a problem report on your premier support account, that should be sufficient for the support team to work on it.

Typically, there's not much you can do about ICE but drop options to see if those are associated with it, or drop back to a compiler version which succeeds.

Interesting - I have never seen "specification exception" before... But Tim's advice is spot-on. Generally when working on ICEs I start removing pieces of code (by commenting or using #if 0), and dropping USE statements if possible, until I get a small source that reproduces the error. This is easier sometimes than others. You can also, as Tim suggests, drop compiler options to see what minimal options are needed to reproduce the error.

Retired 12/31/2016

Hi Tim: It's not really my code to distribute but I'll see what I can do. The ICE seems to be related to one external module; if I comment out the use of that particular module, the files compile OK. However, the "use"s are nested quite deeply; so, it is difficult to find a minimal case.



Steve Lionel (Intel) wrote:

 as Tim suggests, drop compiler options to see what minimal options are needed to reproduce the error.

My sole compiler options are "-c" and "-I path/to/modules". I think I've got my work cut out for me.

As ever: Thanks,

You could start with -O0 and see if that changes anything.

Usually when it's several sources that get the error, it has to do with some module file it uses. So see my advice above for how to narrow it down. You may find that one or more modules it uses also need the whittling-down treatment.

Retired 12/31/2016

When you dig through your code check to make sure your modules do not have circular references (sometimes this is quite difficult to ascertain). If you have circular references then the dependency order cannot be automatically determined (sometimes this causes older mod to be used then affected mod gets compiled). Try to eliminate any circular references.

I've seen cases (in older versions of the compiler) where appropriate Project Dependencies are not checked (old dependent on mod files may not get built) and/or build order not correct. Examine and fix if necessary.

If you think all is in order Clean and/or delete the .obj and .mod files then Build.

Jim Dempsey

Well ... this won't help you in your search but I ferreted out when the "specification exception" assert is happening;  as a result of a SIGBUS signal.   A google search pretty much confirmed that SIGBUS comes from improper memory handling, which everyone has been assuming right along. 



Using Lorri's lead... I found "You can also get it from accessing a memory mapped device if there's an error of some kind."

Is your system disk or page file on an SSD or hybrid disk?

Jim Dempsey

I also found "If the kernel fails to page in a code page due to memory pressure..."

Try disabling IOP, first multi-file, then all IPO. IPO generally increases memory pressure. If this works, then see if you have a process memory limitation set too small, and/or page file limitation set too small. Note, a virtual memory allocation could be made that exceeds the remaining space to the end of page file limit and/or process limit. i.e. front of allocation is available, back is not. Linux (and other O/S) do not acquire the page file space or physical RAM until "first touch". IOW the compiler may be performing an allocation that succeeds (Virtual Address Space available), but then later fails upon  "first touch".

Jim Dempsey

Hi: I have reduced my failing program down to a few files. I have also anonymized the code. The problem appears to begin with these declarations in module e:

  type, public :: e_0
    integer :: i_0 =  0
  end type e_0
  type(e_0), public, target, allocatable :: e_1(:)

This array is used in a public function, d::d_0, to provide the dimensions of a couple of local variables. d_0 is called by several functions in b. A totally unrelated function, b::b_10, is called by the function in a.F90. When a.F90 is compiled, I usually get the specification exception. Sometimes, instead of "specification exception" I see "segmentation violation signal raised". I suspect this is due to address-space-layout-randomization, but that's just a wild guess. Infrequently the compile even succeeds; I don't know what that means.

I have a kind of work-around: If I ALLOCATE the local arrays in d::d_0, it compiles OK.

The error occurs with ifort 13.0.1 20121010 on RHEL 6.4 or 13.1.1 20130313 on CentOS 5.6 (64-bit). Furthermore, with ifort 20130118 on windows xp, I get this message when compiling a.F90:

fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for a.F90 (code 1)

I attached a tar file with my reduced example code and with a short Makefile. It should be enough to just do "make" to see the error.

Thank you, Jim and Lorri, for your suggestions.



Downloadapplication/x-gtar ice.tgz1.68 KB

Thanks, we'll take a look.

Retired 12/31/2016

This is actually the same problem as reported in . We have this fixed in our sources for a release later this year. There is a simple workaround. In function d_0 add the line:

use e, only: e_1

The problem occurs when you use a module entity that comes from a USE in a host scope (in module d here) in a specification expression. This causes us to corrupt our "table" of module entities resulting in various symptoms. The workaround is to move (or add) the USE into the procedure where the module entity is used. We apologize for the inconvenience, and thank you for taking the time to provide a small test case.

Retired 12/31/2016

Excellent. I applied that change to my problem code and it did the trick. It compiles cleanly (well, except for the raft of #8577 remarks :-).

Thanks again!

Leave a Comment

Please sign in to add a comment. Not a member? Join today