BEWARE of internal compiler errors (ICE): Intel Compiler XE 2013

BEWARE of internal compiler errors (ICE): Intel Compiler XE 2013

Based on past forum topics, I suppose unexpected internal compiler errors (ICE) has been a problem with any upgrade with past versions of Intel compilers, but this was a first for me. I recently upgraded to Fortran Compiler XE 2013 from XE 2011 and code that has worked without errors for nearly 15 years in Compaq Visual Fortran as well as Intel Fortran 9 and XE 2011 started giving an internal compiler error (ICE C00005). Based on previous Steve Lionel's responses to similar errors on many posts in this forum and the fact that this code has worked without errors in previous versions, I figured it is a compiler bug and attempted several code tweaks such as removing/inserting comment lines, creating code listings, etc. After many failed attempts at such code tweaks, I hit upon a USE statement that did not have a ONLY keyword; I modified the statement to have the ONLY keyword to only access the needed entities from the module and voila, the ICE disappeared! That is,

USE MyModName


USE MyModName, ONLY : PublicVar1, PublicVar2

Owing to the proprietary aspect, I can't post the exact code here. But I'll try to isolate and simplify the code and submit to Intel Premier Support and they can hopefully fix the issue in one of the future updates to Compiler XE 2013.

For those of you who can't turn the "ship around" and can't wait through the Intel update cycle for bug fixes, the above information is just to let you know minor code changes - note they could be anything, not necessarily USE statements - might help you get around this issue. In my case, my preference is always to include the ONLY keyword on all USE statements and there was a silver lining after all. I understand it may not be the case always.

Separately though, it is distressing to come across such compiler bugs. I can understand if they were to happen with the newer Fortran 2003/2008 features, but not with fairly standard Fortran 90/95 that has been handled since the days of Digital Fortran circa late 90s. Can any of the Intel staff shed some detail on what's commonly the root cause of such regressions in their compiler versions?

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

Dear FortranFan,

I would have to say you seem to be trying to start an 'anti-Intel Fortran' campaign since you throw accolades at Compaq Fortran (which i used for many years and didn’t find all that great and  I have found INTEL Fortran an exponential improvement!).

With any and ALL products on the marketplace, particularly those which try to be backward compatible, and work on 32-bit, 64-bit, Linux, Windows and the kitchen sink, you will occasionally find issues which can produce an ICE.

The USE statement you cite cannot possibly be the issue since i use those frequently, with and without ONLY. Where you might run into a problem is if the ONLY variables are also defined in another Module or as a subroutine name or some other conflict. However in those instances it generally will throw an error message and not an ICE.

I am sorry for the issues you are having and i "feel your pain" as I understand how frustrating these types of issues can be.

My main recommendation is: clearly state the problem you have encountered and try to create sample code which produces the problem and then the folks at INTEL Fortran will assist you in resolving the problem, whatever its cause.

Dear bmchenry,

"I would have to say you seem to be trying to start an 'anti-Intel Fortran' campaign.." - I'm sorry if you got such an impression because I'd no such intent at all.  I was only trying to make two points and I wish I'd stated them better:

a)  Internal compiler errors (ICEs) can be due to compiler bugs rather than errors in one's code.  Yet, some minor code tweaks can sometimes help one get past them which may be useful if the compiler bug fix is months away.  And if these code tweaks improve one's code, then all the more the better.

b)  Other than "regression" in Intel XE 2013, there is no reason why my code should have encountered an ICE.  This code is based mostly on standard Fortran 90/95 features; the only thing non-standard is the use of !DEC$ compiler directives to enable mixed-language programming with C/C++.  It has worked well for a long period of time - it gets used by over 3000 people in thousands of calculations every day in my organization.  And it has compiled without errors in Digital Fortran 5 through Compaq Fortran 6.6C as well as Intel Fortran 9 through XE 2011.  None of this is meant to imply my code is 100% perfect or that all these past compiler versions were superior.  Just that when things "break" unexpectedly in a new compiler version and no other information is readily available, one wonders if it is an isolated problem with the new compiler or a more systemic issue with quality control.

I fully appreciate the vastness, the benefits, and complexity of all the enhancements going into Intel Fortran and I'm very happy a big name such as Intel is helping Fortran live and thrive!  But at the same time, we all should be able to expect Intel will "break" few existing features, if any at all.  I write all kinds of code and I'm extremely sympathetic to "bugs" that get introduced when one is making all sorts of improvements.  But that's why one does extensive "regression testing".  Since I see a lot of ICEs getting mentioned in connection with new compiler versions on this forum, I was only wondering aloud if the "regression testing" and QA/validation of existing capabilities in newer versions needed some improvement i.e., better work processes, more staff, more or better test cases, etc. i.e., better quality control overall.  If the general consensus amongst users is "regressions" are few and far in between, then Intel has nothing to think about. 

I believe strongly Intel Fortran is the best Fortran compiler for Windows and Linux platforms running on Intel hardware.  I expect to remain a customer as long as Intel remains in this business. 


Separately, I want to apologize to all about the duplicate posting: here's the other listing on the same topic.

I was having problems with using this form on Internet Explorer 8 and I thought my first attempt at posting had failed, so I tried a second time.

Leave a Comment

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