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
連結已複製
36 回應
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?
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
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
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
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
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,
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
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
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.
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:
[cpp] 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 [/cpp]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!
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!
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!
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!
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
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.
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.
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.
Dave, thanks for the additional information.
