2 internal compiler errors (C0000005)

2 internal compiler errors (C0000005)

 Hi @all,

 hopefully this is the right place for this question :-)

I've got a small sample project, which produces 2 different internal compiler errors (C0000005) using the 13 branch of the compiler.

When compiling with version 12 those errors do not occur.

Could anyone of the Intel fellows have a look at it and forward it to the compiler crew in order to remove those bugs?

Thanks in advance






18 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Andreas,
If you can provide the code which causes the error the people at Intel would be better able to identify the cause.


Hi Les,
of course you're right :-)
I just wanted to make sure somebody is able to forward the code to the developers.
But anyway,
I've just added the whole testproject.
Keep in mind that it doesn't make much sense, because it's actually just 2 different projects stripped down to one test case being able to reproduce the internal compiler errors.


Downloadapplication/zip testproject.zip67.49 KB

In LMG3_INTERFACE.FOR you have, for the case ITLUPE=1, pointer assignments such as

ptr_samg_set_logio => samg_set_logio.
However, since samg_set_logio is merely an abstract procedure name, and not a "concrete" procedure, internal or external, the assignment does not make sense.

The compiler ought to flag this as an error. GFortran says, for example:

Error: Abstract interface 'samg_set_logio' is invalid in procedure pointer assignment at (1)

Is this the true problem in your real application as well, or the result of an oversimplification during the paring down process in preparation for posting a small enough example here?

Hi Mecej4,
thanks for looking at the code :-)
As I said: this sample doesn't make any sense due to a lot of lacking things.
What it should demonstrate is that the compiler itself produces internal errors - meaning it crashes during compilation.
So it makes obviously no sense trying other compilers (and the sample probably wouldn't compile anyway).
What the compiler should do is avoiding to crash, but producing error messages (like GFortran does).
Once this is achieved, I'm pretty optimistic, that my real projects compile too - as they do with the version 12.x of Intel Fortran.


Thanks for the example code - I'll take a look at it and forward to the developers. This forum is a fine place to report such things.

Retired 12/31/2016

Thanks :-)

The issue with LMG3_INTERFACE.FOR is exactly as mecej4 says - a coding error that should result in a meaningful error message from the compiler but doesn't. This has been escalated as issue DPD200238782. The problem also reproduces with the 12.1.5 compiler. We'll fix this, but it may be a while since errors for incorrect programs have lower priority. You'll need to figure out what you really intend here and fix the source.

I'll look at the other one next.

Retired 12/31/2016

I can't get modcal.f90 to show an internal compiler error. Please attach a ZIP of the buildlog.htm showing the error.

Retired 12/31/2016

Hi Lionel,

ok: attached you find the Buildlog you requested showing the error.

I've attached the original LMG3_INTERFACE.FOR too.
This is to show you, that it is no programming error.
The abstract functions you're refering to are to be found in an external DLL.
As I said this compiles without any error with Intel Fortran
Versions above that produce the fatal error (up from 12.0.6).
So it would be great to give this issue a higher priority :-)
Best regards


Downloadapplication/zip files.zip10.57 KB

Ok - in IA-32 Release mode I can get an internal compiler error for the second file. I will report that.

LMG3_INTERFACE.FOR is incorrect for the same reasons as stated above. Yes, it seems to compile without error in 12.0.5, but that's even worse than getting an ICE because the source is wrong. You do a pointer assignment where the target is the name of an abstract interface. There is nothing that ties this to a routine in a DLL. I don't know what the compiler did in 12.0.5, but it can't be anything right.

Retired 12/31/2016

The issue with modcal.f90 seems oddly sensitive to command line length! If I drop any options, even those that should have zero effect (for example, the /warn:ignore_loc) or even change the path to the source file , the error goes away. I also can't get it to show with an internal debug compiler. Hmmm.....

Retired 12/31/2016

Hi Lionel,

as for the error regarding LMG3_INTERFACE.FOR I changed all subroutine interfaces from abstract / external to DLLIMPORT.
I've attached the corresponding file and hope I got it right?
But nevertheless the compiler crashes - this time the 12.0.5 version too...
In order too compile it you have too switch to extended fixed form line length (132 columns).

As for the other issue:
Are you gonna inform me here once it's solved or do you have an issue number for which I could look for in the Release Notes?



Downloadapplication/octet-stream lmg3-interface.for53.64 KB

I have not yet escalated the other issue as I am still working on isolating the issue. But once I do I will give the issue number here and will update this thread with progress.

The revised lmg3-interface file seems to be running into a different bug - it happens elsewhere in the compiler. Working....

Retired 12/31/2016

The issue with modcal.f90 has been escalated as issue DPD200238892. The revised lmg3-interface.for error is escalated as issue DPD200238905, but it has an easy workaround. Remove "DLLIMPORT," from all the ATTRIBUTES directives. You don't need them and removing them will allow this to compile. The error requires that you do a procedure pointer assignment of a DLLIMPORTed external where the pointer is a dummy argument.

Retired 12/31/2016

Hi Steve,
(sorry for calling you Lionel before absentmindedly...)

Thanks for your help.
As you told me, I removed all "DLLIMPORT" and now it compiles with both compiler versions.
I didn't have to do the procedure pointer assignment to a dummy because I'm doing this assignment anyway to the ptr_samg_***** variables.
Once this issue is resolved I'm just gonna put back the "DLLIMPORT"s even if they're not needed.

As for the other issue, I'm just gonna check the Release Notes of the next compiler updates.

Thank you very much!
Best regards

Actually, you'll want to check the "README" file that is posted alongside the product update at the Intel Registration Center, or the Compiler Fix List article. The release notes themselves do not list individual fixes. I will update this thread as the issues are fixed.

For procedures, DLLIMPORT is optional. Using it removes an instruction or two when the procedure is called, but it's functional either way. For variables you're sharing with a DLL, DLLIMPORT is required.

Retired 12/31/2016

The problem with LMG3_INTERFACE.FOR is fixed for a future version. (This was an incorrect program that triggered an internal compiler error.)

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today