Sudden internal compiler error

Sudden internal compiler error

Bild des Benutzers 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...

19 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers iliyapolak

<<>>

It looks like access violation error.Probably during compilation bad memory pointer was dereferenced.

Bild des Benutzers 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.

Bild des Benutzers Steve Lionel (Intel)

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

Steve
Bild des Benutzers 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.

Bild des Benutzers Steve Lionel (Intel)

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.

Steve
Bild des Benutzers 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?

Bild des Benutzers David White

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

Bild des Benutzers iliyapolak

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

Bild des Benutzers 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.

Bild des Benutzers iliyapolak

Zitat:

nvaneck schrieb:

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.

Bild des Benutzers 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.

Bild des Benutzers iliyapolak

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

Bild des Benutzers Steve Lionel (Intel)

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.

Steve
Bild des Benutzers 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 

 

Bild des Benutzers Steve Lionel (Intel)

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

Steve
Bild des Benutzers nvaneck

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

Bild des Benutzers 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.

Bild des Benutzers 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...

Melden Sie sich an, um einen Kommentar zu hinterlassen.