Internal compiler error on using a polymorphic type.

Internal compiler error on using a polymorphic type.


I have encountered a problem with Intel Visual Fortran compiler [IA-32]. The compiler crashes with a cryptic message:

1>fit_lookup: Line_seq_number 00000000 was not found
1>fortcom: Fatal: There has been an internal compiler error (C0000005).
1>compilation aborted for XXXXXXXXXXXXXXX\oouseB.f90 (code 1)

I prepared a simple reproducer that illustrates the problem at hand. In the attachment you can find three files:

  1. oomodule.for that encapsulates three polymorphic derived data types inside the module oomodule. These data types are: base_type, A_type, B_type and X_type.
  2. oouseA.f90 that contains the module oouseA, which simply uses oomodule
  3. oouseB.f90 that contains the module oouseB, The module oouseB uses both oomodule and oouseA. The module oouseB references the derived data type base_type.

The compiler crashes on processing the third source file (oouseB.f90).

To facilitate analysis of the case, I added a few preprocessor directives that can switch off selected parts of the code.  I have to remark that the preprocessing has nothing to do with the reported crash. Originally I have encountered the problem while developing a code that does not use the fpp at all.

More in detail:

  1. preprocessor macro A_type_INIT_ENABLED enables a trivial generic interface for initization of A_type instances. If the code does not define the interface A_type, the problem with the compiler crash vanishes.
  2. preprocessor macro A_type_CONTENT_ENABLED: if it is defined, the compiler crashes in the way I described above. However, if I leave it undefined, which in turn simply adds one member field to the data type A_type, the compiler dumps different error message:
    1>XXXXXXXXXX\LOCALS~1\Temp\47043.i90: internal error: Please visit '' for assistance.
    1>[ Aborting due to internal error. ]
    1>compilation aborted for C:\work\temp\ooproblem_reproducer\oouseB.f90 (code 1)
  3. preprocessor macro X_type_CONTENT_ENABLED: by leaving it undefined we remove a reference to the type B_type from the type X_type. Apparently, this results in disappearance of the compilation crash.
  4. preprocessor macro USE_ONLY can be used to switch regular "use oomodule" into selective "use oomodule, only:  base_type, A_type, B_type, X_type". The list of the used items contains all public components of the module oomodule, so it would be just equivalent to the regular "use oomodule". Surprisingly, the selective "use"  statement makes the internal compiler error disappear.

I admit there can be a problem with the code I posted. If it would be the case, I would greatly appreciate pointing the errors out to me.

The code was tested with the versions and [IA-32], both on WIN32.
The problem was also reproduced with Ifort 12.1.3 20120212, Linux EMT64. In this case the error message was:

fit_lookup: Line_seq_number (nil) was not found
/tmp/ifortF9cmyT.i90: catastrophic error: **Internal compiler error: segmentation violation signal raised
** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  
Note: File and line given may not be explicit cause of this error.
compilation aborted for oouseB.f90 (code 1)

best regards,

Downloadapplication/octet-stream oousea.f90107 bytes
Downloadapplication/octet-stream oouseb.f90489 bytes
Downloadapplication/octet-stream oomodule.f902.87 KB
6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Thanks - we'll take a look.

Retired 12/31/2016

Thanks for the excellent test case and description. I was able to reproduce the problem and have escalated it as issue DPD200238332.

Retired 12/31/2016

Dear Steve,

thanks your your prompt reply.

Could you give me any hint if the workaround I described in point #4 can be safely used in a long run?

best regards,

I don't see why not.

Retired 12/31/2016

This problem has been fixed for a release later this year. Unfortunately it is too complex to go into an update.

Retired 12/31/2016

Leave a Comment

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