Internal Compiler Error (11.1.051)

Internal Compiler Error (11.1.051)

Dustin's picture

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

37 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Steve Lionel (Intel)'s picture

An internal compiler error is almost always a compiler bug. Are you willing to provide us the source and the compile options you used so that we can investigate it?

Steve
Dustin's picture
Quoting - Steve Lionel (Intel)
An internal compiler error is almost always a compiler bug. Are you willing to provide us the source and the compile options you used so that we can investigate it?

Okay,what is the best way to get you the file?

Dustin's picture
Quoting - Dustin
Okay,what is the best way to get you the file?

Nevermind, I noticed the sticky with instructions.
Here are the files. They are compiled as follows:

ifort astap.for /fpe:0 /names:lowercase /iface:cref /module:C:PROGRA~1CULLIM~1SINDAF~1lib /MT /libs:dll /iface:mixed_str_len_arg /include:C:PROGRA~1CULLIM~1SINDAF~1lib /assume:byterecl /extend_source:132 /O3 /list /traceback /INCREMENTAL:NO

Attachments: 

dave@crtech.com's picture

I'm sure you will need the module file as a minimum to compile this so I have uploaded it here. If you need the libraries too just ask. But you won't be able to run the resulting executable without doing a lot more.

Dave

Attachments: 

AttachmentSize
Download workary.mod1.35 KB
Dustin's picture
Thanks, Dave. Sorry to jump the gun, but I got a little impatient. Plus, I wanted to get to know the Intel folks.
Steve Lionel (Intel)'s picture

I'll need the source for the module(s) - thanks. Feel free to ZIP them if they're big.

Steve
dave@crtech.com's picture

I have attached the source for the module. But I'm really curious as to why you need it? It isn't every used outside of building the library. Is it the source of the problem? Seems it took almost 3 hours on my machine to compile the source before it failed with the internal compiler failure.

Dave

Attachments: 

AttachmentSize
Download workary.for351 bytes
Steve Lionel (Intel)'s picture

Sometimes there is an issue with the .mod and we need to see the source that created it. Thanks for providing it. I'll let you know what we find.

Steve
dave@crtech.com's picture
Steve,

Just so you know, we have submitted a bug report that deals with ALLOCATION/DEALLOCATION across compiler versions. Maybe that is why you wanted this source, but the variables are allocated in the main routine.
I still haven't gotten a fix date for that problem. But we have a work-around, we just haven't implemented it yet.

Dave

Steve Lionel (Intel)'s picture

Thanks - I know about that issue. Unfortunately, it's one we won't be able to provide a solution for other than not mixing allocations across 11.0 (and earlier) with 11.1 (and later).

What is this ASTAP program? It looks to be automatically generated. It may be that it's just too complex a single program unit for the 32-bit compiler. To be honest, I doubt optimization will help since it's very simple in nature (lots of calls.)

Steve
dave@crtech.com's picture

Steve,

The code is generated programatically. This is being compiled for 64 bit machines in this case. What do we need to do to get past the compiler failure. Are you going to look for the failure in the compiler?

Dave

Steve Lionel (Intel)'s picture

Yes, I will certainly look (or ask the developers to look) for the failure. If I can find a workaround, I'll let you know.

Steve
dave@crtech.com's picture
Thanks! I haven't been able to get very far with working around this one.
cgerdb's picture
Quoting - Steve Lionel (Intel) Yes, I will certainly look (or ask the developers to look) for the failure. If I can find a workaround, I'll let you know.

Hi! Steve,

I am new to this forum. I notice you are an expert here. I got the same internal comiler error as well with Visual Fortran 11.1.051 inside Visual Studio 2008 in 64bit XP. Let me give you a very simple example here:

      program Console1

      implicit none

      CHARACTER*10 FNAME
      DATA FNAME /'ABCDEFG'/
      INTEGER I, J

       DO J=1,LEN(FNAME)
!         IF (J.NE.3) THEN
         IF (FNAME(J:J).NE.' ') THEN
           I=I+1
         ENDIF
       ENDDO

     
      end program Console1

The compiler is OK with the commented IF line, but give error for the next IF line. However, compiling the code in a console window with ifort is fine with both IF lines.

I cannot understand this. Please help!

Steve Lionel (Intel)'s picture

cgerdb, I see you started a new thread - I replied to you there.

It is important to understand that "Internal compiler error" is a generic message with many, many possible causes.

Steve
Steve Lionel (Intel)'s picture

Dave,

What I can tell is that the compiler is simply running out of virtual memory. It takes longer on a 64-bit system, but it does eventually happen. I've asked the developers to look into it, but may not be able to provide a workaround. That is one enormous subroutine!

Steve
dave@crtech.com's picture
Quoting - Steve Lionel (Intel) Dave,

What I can tell is that the compiler is simply running out of virtual memory. It takes longer on a 64-bit system, but it does eventually happen. I've asked the developers to look into it, but may not be able to provide a workaround. That is one enormous subroutine!

Yes but even breaking it down into smaller pieces still results in the same error. I chopped it down to about 50000 lines each and it still fails. There aren't that many variables involved, so it is very puzzling why the compiler fails. And the fact that it takes 3 hours to fail seems to suggest there is a compiler bug involved. I've compiled much larger sources without this many problems. Seems like a solvable problem. I also turned off optimization, so that shouldn't be an issue. Anyway we are still hoping for some resolution on this.

Dave

cgerdb's picture

I solved my Internal Compiler Error with an inspiration from Steve. It may work for you too. Try these:

1) Click "Prject" menu and then "your_project_properties" item;
2) Click "Fortran" and then "Run-time";
3) Set "Chech Array and String Bounds" to "no";
4) Build.

Steve Lionel (Intel)'s picture

Dave's problem is different and can be seen even with no compiler options. As I said, an internal compiler error message can have many possible causes. You cannot assume that one case is like another.

Dave, thanks for the additional information.

Steve
dave@crtech.com's picture

Steve,

Is this related to DPD200140603? Any chance 11.1.054 fixes this? Do we need to submit a report to premier support to make sure we get an answer on this?

Dave

Steve Lionel (Intel)'s picture

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.

Steve
Lorri Menard (Intel)'s picture
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

Steve Lionel (Intel)'s picture

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

Steve
dajum's picture

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

Thanks,

Dave

Steve Lionel (Intel)'s picture

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

Steve
Steve Lionel (Intel)'s picture

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.

Steve
Steve Lionel (Intel)'s picture

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.

Steve
dajum's picture

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

dave@crtech.com's picture

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's picture

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.

dave@crtech.com's picture

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.

dave@crtech.com's picture

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.

Tim Prince's picture

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.

Steve Lionel (Intel)'s picture

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?

Steve
dave@crtech.com's picture

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

Steve Lionel (Intel)'s picture

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

Steve

Login to leave a comment.