Sudden internal compiler error

[nvaneck]

Recently I've started getting several errors like

C:\Development\Projects\MicrOsiris\SUBS\GCAT.F90(1): error #7001: Error in creating the compiled module file.   [GCAT__genmod]

fortcom: Fatal: There has been an internal compiler error (C0000005).

compilation aborted for C:\Development\Projects\MicrOsiris\SUBS\GCAT.F90 (code 1)

Usually they go away when I recompile the individual routines, but not this time.  I'm using version  11 of the compiler.  Thjese errors didn't crop up last year, but just this year when making some changes in urelated routines.

What is happening here? I can 't afford upgrading to the latest version...

[Bernard]

<<< ="" there="" has="" been="" an="" internal="" compiler="" error="">>> It looks like access violation error.Probably during compilation bad memory pointer was dereferenced.

[nvaneck]

Thanks, that could explain it.

Actually, I'm using

Intel(R) Visual Fortran Composer XE 2011 Update 7 Integration for Microsoft Visual Studio* 2010, 12.1.3518.2010

The problem went away again when I compiled it separately in release mode and then again in debug mode.

Mysterious, but at least I can still proceed.

[Steven_L_Intel1]

Internal compiler error is always a compiler bug.  Are you willing to provide the source(s) and options needed to reproduce it?

[nvaneck]

Perhaps, but it may not be reproducible; it seems random, primarily when every routine needs recompiling, and not always the same routine exhibits the problem. Complete project is large, and recompiling a single routine usually clears it up.  I'll try a few complete rebuilds and see what happens.

[Steven_L_Intel1]

If that's the case, then I would suspect a problem on your system - perhaps bad memory or disk, or a background program that interferes with the compile.

[IanH]

I have seen "random" compiler issues result from generated interface blocks - whether these are present or not depends on compile order and perhaps compile history, both of which have some "randomness" about them.  For example - a build after a clean works, but a rebuild of selected source files after the majority have been built previously fails. Deleting the generated __genmod.mod files prior to a build of a problematic file was part of the proof/solution for me.

This scenario requires a) generated interface checking to be active; b) your source having external subprograms that result in the compiler spitting out the __genmod bits; c) you meet the other associated with the compiler bug (memory fades, but it would have been something related to CLASS arguments) and d) the compiler bug to still be extant (it has been a while since I checked my list).

Do a) and b) apply in your case?

[DavidWhite]

Ian,

your comment about whether generated interface blocks are present or not reminds me of issues I have encountered when I permit parallel compilation of my projects - allowing only one compile in parallel seems to ensure that this sort of issue does not arise.

It's not clear whether the OP was attempting parallel compiles; if so, this may be worth trying.

David

[Bernard]

>>>If that's the case, then I would suspect a problem on your system - perhaps bad memory or disk, or a background program that interferes with the compile>>>

Probably system related issue.

[nvaneck]

Memory checks come up ok.

It did crop up for one file after a clean.  Problem seems to occur only with debug configuration.  Problem occurred with an older backup copy of the project I just ran. Other factor involved is I did change the location of the project from a separate disk to the system disk, but no disk problems detected on system disk.

[Bernard]

nvaneck wrote:

Memory checks come up ok.

It did crop up for one file after a clean.  Problem seems to occur only with debug configuration.  Problem occurred with an older backup copy of the project I just ran. Other factor involved is I did change the location of the project from a separate disk to the system disk, but no disk problems detected on system disk.

If you are more interested in finding the root cause of the problem I would advise to collect the process dump file.

[IanH]

I recall experiencing sporadic internal compiler errors generated when mod files from older (minor) versions are fed to a newer compiler (or perhaps it was vice versa).  Given the workaround (rebuild!) is trivial and the mix of versions in a build was unintentional it was not something I bothered to isolate further.

(Those mod files could also be the interface checking variant rather than ones that correspond to the users source modules.)

Debug builds are likely to involve interface checking.  Do you have any external subprograms - procedures that are not in a module?

The reason that I mention interface checking is because sometimes you need to do something twice in order to see a crash (a plausible alternative is that it might only be the first time after a clean that something goes wrong).

I now feel silly - looking at your original report in more detail - note the __genmod.  The likelihood of this being a problem with interface checking is rather high.  If the errors are causing problems and you cannot upgrade you will either need to disable interface checking or investigate particular compile orders that avoid triggering the problem (to force a compile order you have to do this manually within Visual Studio - i.e. after a clean pick files that you want to compile first, compile them using Build > Compile as necessary, then use Build > Build projectname to finish the rest off in whatever order the integration deems suitable).

I don't understand what use a process dump file of the compiler would be to an independent (non-Intel) programmer.

[Bernard]

>>>I don't understand what use a process dump file of the compiler would be to an independent (non-Intel) programmer>>>

For independent programmer dump of crashed compiler won't be usefull.Only if someone is interested more in investigating program(compiler) crash either running compiler process under debugger or collecting compiler dump would be usefull.

[Steven_L_Intel1]

Don't bother with the process dump file - it isn't something we can use. I agree with Ian that generated interface checking may be the culprit - turn that off and see if the problem goes away. We have fixed a number of problems like this since version 11.

[nvaneck]

This is weird:

When I turn off interface checking and do a build, I get a raft of other spurious errros which disappear with a subsequent build for the routines with "errors"

Error 7  error #6303: The assignment operation or the binary expression operation is invalid for the data types of the two operands. C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 28  Error 14  error #6303: The assignment operation or the binary expression operation is invalid for the data types of the two operands. C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 32  Error 17  error #6303: The assignment operation or the binary expression operation is invalid for the data types of the two operands. C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 34  Error 32  error #6341: A logical data type is required in this context.   [NOMEM] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 41  Error 16  error #6341: A logical data type is required in this context.   [PART_WHOLE] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 33  Error 37  error #6341: A logical data type is required in this context.   [REGR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 44  Error 22  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [MAX] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 39  Error 23  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NCOR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 39  Error 24  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NCOR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 40  Error 25  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NCOR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 40  Error 26  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NCOR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 40  Error 27  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NCOR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 40  Error 28  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NV] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 40  Error 29  error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [NV] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 40  Error 33  error #6404: This name does not have a type, and must have an explicit type.   [ALPHA] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 43  Error 9  error #6404: This name does not have a type, and must have an explicit type.   [FATAL] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 31  Error 6  error #6404: This name does not have a type, and must have an explicit type.   [IS_R_MD] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 28  Error 21  error #6404: This name does not have a type, and must have an explicit type.   [MAX] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 36  Error 5  error #6404: This name does not have a type, and must have an explicit type.   [MAX_DIM] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 23  Error 18  error #6404: This name does not have a type, and must have an explicit type.   [NCOR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 36  Error 30  error #6404: This name does not have a type, and must have an explicit type.   [NOMEM] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 41  Error 8  error #6404: This name does not have a type, and must have an explicit type.   [NTOT] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 30  Error 19  error #6404: This name does not have a type, and must have an explicit type.   [NV] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 36  Error 13  error #6404: This name does not have a type, and must have an explicit type.   [PART_WHOLE] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 32  Error 35  error #6404: This name does not have a type, and must have an explicit type.   [REGR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 44  Error 12  error #6404: This name does not have a type, and must have an explicit type.   [REPVAR] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 32  Error 34  error #6404: This name does not have a type, and must have an explicit type.   [SCR1] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 43  Error 4  error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [CORRELATIONSMOD] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 10  Error 3  error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [IMATIN] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 2  Error 2  error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [IMATOUT] C:\Development\Projects\MicrOsiris\PGMS\CORRELATIONS.F90 2 

[Steven_L_Intel1]

Try a "rebuild". It looks as if not all of the modules got built.

[nvaneck]

Yes, the rebuild clears them up.  I think I may need to reinstall fortran.

[mecej4]

There is probably no need to reinstall the compiler. When you change from Debug to Release (or vice versa), if you make a habit of doing a "clean" before building again, many of these problems may go away.

[nvaneck]

Maybe, but I've used it for years without these problems, and now they happen all the time, even after multiple clean and rebuilds...