topic Maybe, but I've used it for in Intel® Fortran Compiler

Sudden internal compiler error

nvaneck — Mon, 25 Mar 2013 14:43:22 GMT

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 — Mon, 25 Mar 2013 15:12:48 GMT

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

TYhanks, that could explain

nvaneck — Mon, 25 Mar 2013 16:37:00 GMT

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.

Internal compiler error is

Steven_L_Intel1 — Mon, 25 Mar 2013 20:10:33 GMT

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

Perhaps, but it may not be

nvaneck — Mon, 25 Mar 2013 21:42:50 GMT

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.

If that's the case, then I

Steven_L_Intel1 — Tue, 26 Mar 2013 00:12:30 GMT

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.

I have seen "random" compiler

IanH — Tue, 26 Mar 2013 00:40:11 GMT

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?

Ian,

DavidWhite — Tue, 26 Mar 2013 01:47:23 GMT

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

>>>If that's the case, then I

Bernard — Tue, 26 Mar 2013 04:23:58 GMT

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

Memory checks come up ok.

nvaneck — Tue, 26 Mar 2013 06:43:12 GMT

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.

Quote:nvaneck wrote:

Bernard — Tue, 26 Mar 2013 07:13:01 GMT

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.

I recall experiencing

IanH — Tue, 26 Mar 2013 07:42:24 GMT

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.

>>>I don't understand what

Bernard — Tue, 26 Mar 2013 07:49:58 GMT

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

Don't bother with the process

Steven_L_Intel1 — Tue, 26 Mar 2013 14:40:26 GMT

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.

This is weird:

nvaneck — Tue, 26 Mar 2013 15:59:31 GMT

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

Try a "rebuild". It looks as

Steven_L_Intel1 — Tue, 26 Mar 2013 16:10:41 GMT

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

Yes, the rebuild clears them

nvaneck — Tue, 26 Mar 2013 17:09:00 GMT

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

There is probably no need to

mecej4 — Tue, 26 Mar 2013 17:51:07 GMT

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.

Maybe, but I've used it for

nvaneck — Tue, 26 Mar 2013 21:29:01 GMT

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