Internal Compiler Error (11.1.051)

[Dustin]

In an attempt to compile a large program with largematrices usingversion 11.1.051 (64-bit), I received the following error message:

fortcom: Fatal: There has been an internal compiler error (C00000FD).
compilation aborted for astap.for (code 1)

I can compile and run smaller versions of the same program, so I wonder if I've encountered a compiler limitation?

Please advise.

Thanks,
Dustin

[Steven_L_Intel1]

I'll check on that issue for you on Monday. You'll get an answer here, but if you want to submit it to Premier Support, you certainly can.

[Lorri_M_Intel]

Quoting - Steve Lionel (Intel)

I'll check on that issue for you on Monday. You'll get an answer here, but if you want to submit it to Premier Support, you certainly can.

Update 4 should have the fix for DPD200140603.

Please let us know if it does not work for you.

thanks --

- Lorri

[Steven_L_Intel1]

The failure to compile ASTAP.FOR is issue DPD200158130. Routine VA0012 seems to be the culprit - it is of course the largest in this file (more than 22MB).

[dajum]

Can you tell me when that issue is set to be fixed?

Thanks,

Dave

[Steven_L_Intel1]

When I find out I will let you know. It is not yet fixed.

[Steven_L_Intel1]

We finally figured out what was going wrong here - an algorithm in the compiler that was order O! that had issues with a 350K line IF block. This has been rewritten, but I don't yet know when the fix will appear.

[Steven_L_Intel1]

With the fix made so far, the source compiles in "only" three and a half hours - with optimization disabled. It will not compile with optimization due to insufficient resources. This fix won't appear in a 12.0 update but will probably be in the next "version", whenever that is. The advice of the developers is that you try to find some way to break up the monolithic IF block into separate routines that are called.

[dajum]

We made alternative methods of outputing this code since our customers usually need a fix in days. But the original method still is available since for many users it works fine since it isn't usually so large.

Thanks.

Dave

[David_J_2]

Steve,

I have found that with Composer XE 2011that code that used to compile in seconds using 11.1.065 now goes for hours (and I'm not sure it will ever finish), without completing the compilation. I have a source that has a routine that is a little over 7000 lines that exhibits this behavior. I haven't tried to find the minimum, but why is Composer so bad? I will try to distill this down and give you the sample unless you don't need it. Is there anything we can do short of re-writing the code? Seems like the compiler should be able to handle 7000 lines of code without going away for hours to think. The next best solution is to return to 11.1.

Dave

[mecej4]

How does the slowdown depend on the compiler options used? Have you tried to notch down the optimization level? How many modules does your problem code USE?

I had seen similar behavior with a large project with an older version of IFort. I was able to pin down a couple of source files that were causing a bottleneck. By compiling just those with /Ot, I was able to obtain decent performance without the letting the compilation speed become a problem.

[David_J_2]

It isn't affected by the optimization. It doesn't really matter if it has modules or not. It appears to matter that there are multiple subroutines in one file. But breaking them out into multiple files seems to take much longer to compile smaller sources (2000 lines in 20 routines), than if they are all in one about 20x longer.

[David_J_2]

What is really frustrating to our users is that the exact same source code and switches in 11.1 takes a few seconds to compile, while using Composer it takes hours. Breaking it up into smaller files helps, but still takes many minutes if not hours.

[TimP]

I suppose you have an application where inclusion of all the default optimizations produces slow compilation of large files with several subroutines. Admittedly, it's difficult to deal with this situation by means other than makefile. ifort supports in-line comment to lower optimization level of individual subroutines to O1, in cases where compact non-vector code is preferred, but you must set /Qip- and the like in the compile options.
I don't remember now which was the last ifort which had a lower than /Qip default level of interprocedural analysis. Maybe it's one you have been using.

[Steven_L_Intel1]

Dave, we would very much like to get an example of this so that we can reproduce it. Question - are any of the source files on a network share, and/or are you using floating licenses with a separate license server?

[David_J_2]

I already submitted it to premier support earlier this morning. No the files are local and there isn't anything funny with the license. This has been verified on several different operating systems and platforms. Pretty consistent across them all. I can upload the .zip file here if you would like. I have several large customers that are backing off from Composer and telling more not to update to Composer from 11.1 to avoid this problem. But I will say it looks similar to the code this thread was originally posted for.

Dave

[Steven_L_Intel1]

No need to upload here if yiou submitted it to Premier Support. Thanks.