catastrophic error: Internal Compiler Error : possible out of order or missing USE

[Olsen__Oystein]

I have attached a small example that generates a catastrophic error. It seems to be caused by a GENERIC ASSIGNMENT operator in a derived type. There are a few ways to make the example compile:

1. Remove the GENERIC :: ASSIGNMENT(=) => setHSString statement in hsstring.f90, since the assignment statement is not used.
2. Remove PROCEDURE, PASS :: errorMessage  from hsdatetime.f90. This function returns a HSString defined in hsstring.f90
3. Remove USE HS2Core, ONLY: EPOCH from hsearthpolygon.f90
4. Change the position of the USE HS2EarthPolygon, ONLY: HSEarthPolygonVector statement in access.f90
5. Change USE HS2String, ONLY: HSString into USE HS2String in errorMessage in hsdatetime.f90 and add a USE HS2String at the start of the module

[Heinz_B_Intel]

Ok - thanks a lot. I didn't see this before I replied to your other case. I will take care of it.

[Heinz_B_Intel]

I escalated the compiler error to engineering: Case number DPD200236510 I will let you know here when a compiler update with a fix will be available

[Lawrence_Patrick__B_]

Dear all,

I am a graduate student running an ocean model that is written in fortran. Here in our university, we are currenly using ifort version 13.0.0. I came across this post because I've been struggling with a similar error message for almost a week now and could not seem to figure out how to solve it. Although I am new to programming in fortran, I can follow the flow of the code, and I've tried things like explicitly specifying the type of the variable involved, or using an earlier version of the compiler. These haven't worked however, and I'm worried it may be a compiler issue for which I am totally unfamiliar with. May I ask for suggestions on possible solutions? I have reproduced the main error message below: 

tide_jcope_v20090702.F(74): error #6404: This name does not have a type, and must have an explicit type. [INIT_SL_TIDAL_HARMONICS%TPOINT]
contains
^
/tmp/ifortZg6Thz.i(1046): catastrophic error: Internal Compiler Error: possible out of order or missing USE
compilation aborted for tide_jcope_v20090702.F (code 1)

[jimdempseyatthecove]

Lawrence

INIT_SL_TIDAL_HARMONICS%TPOINT

Implies (requires) INIT_SL_TIDAL_HARMONICS be a defined type with TPOINT as a member variable. Types can be declared either in the data declaration portion of a procedure (at top) or in a module that is USE'd (at top, above data declarations). It appears that by line 74 in
tide_jcope_v20090702.F that type INIT_SL_TIDAL_HARMONICS has not been fully defined.

In noticing that your sorce file is named with ".F" file type, this implies that the source is "Fixed Source Form" as opposed to files with .f90 being "Free source Form". In "Fixed Source Form" the character positions on the statement lines have strict restrictions. Columns 1:5 were statement lable, column 6 optional continuation character, columns 7:74 statement, columns 73:80 sequence number. If your statement is not positioned within the appropriate fields code would not compile as anticipated. These rules were derived for use with punch cards. Punch cards did not accomodate a Tab character (tab key advanced in spaces on the card to the next Tab stop). Programmers tend to use the Tab key to align code (inserting Tab character in the process). When using Fixed Source Form, the compiler will treat a Tab character as a single Space character (iow, column positions used by compiler will generally not be those observed in editing the program).

Check your program(s) with .F type to see if they have Tab characters if they do, then replace with appropriate number of space characters. Also check to assure no portion of the statement falls outside columns 7:74.

An alternative is to rename your .F files to .F90 (I suggest you copy to new folder using new .f90 type and compiling from there as test).

Jim Dempsey

[Anonymous66]

Hello Lawrence,

 An internal compiler error means you have run into a bug in the compiler. Would you be able to share your code with us? We need to be able to reproduce the problem in order know where the issue and to find workarounds.

Annalee

[Heinz_B_Intel]

The issue (  DPD200236510 ) got fixed by the 14.0 compiler