Intel OneAPI 2024.2: Unidentified "Internal Compiler Error" using the new IFX Fortran Compiler

[Rv49]

INTEL OneAPI 2024.2 downloaded on Os Winsows 11 Pro - Fortran IFORT & IFX compilers

Compiling a source program named XXXX.F90, sized about 3000 code lines, the following happens:

a) using by the commandline the 'old' IFORT compiler, the executable is normally produced

b) using by the commandline the new IFX compiler, the following error message appears:

xfortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for XXXX.F90 (code 1).

and no executable is produced.

What to do? I didn't find on the Compiler Reference answers for this kind of compiler errors.

Another source program, sized about 3000 code lines as well and even a bit larger, is regularly compiled and the executable is obtained both by IFORT and by IFX.

If requested, I can attach the two source programs, the one regularly compiled both by IFORT and IFX and the other regularly compiled by IFORT only.

Thanks in advance to anyone may have found this problem and knows its solution.

Alberto Rivoiro

20145 MILANO(IT)

email: rivoiro.al@alice.it

[Ron_Green]

These Internal Compiler Errors (ICE) can happen for many reasons.  The code does not tell us anything other than that the compiler crashed.  Please do upload the code XXXX.F90 - better yet, if you can zip the entire Solution directory after doing a "Clean"  to remove the object and mod files.  

[Rv49]

Ok Ron_Green, I am attaching:

XXXX.F90  this source is correctly compiled producing the executable by IFORT only. By IFX the Internal Compiler Error is detected.

YYYY.F90  this source is correctly compiled and the executable is produced both by IFORT and by IFX.

Both sources are written in fixed form and have their own modules at the top, immediately followed by the Main (introduced by the PROGRAM  statement) and by all their routines & functions.

On the third attach CONMOD.TXT you can watch a synthesis of the sources dimensions.

The OS on which I downloaded and installed IFX and IFORT is Windows 11 Pro.

The commandlines used to compile are:

IFORT  /fixed  /Qdiag-disable:10448  source_name

IFX  /fixed  source_name

Thank you very much for your attention and best regards,

Rv49

[andrew_4619]

      MODULE NOMD
      INTEGER  (0004) LCDIR(30)
      CHARACTER(0004) QUA
      CHARACTER(1000) HCDIR(30)
      END
      SUBROUTINE DEFILE                                     (ND,HNOMEF)
      USE NOMD
      CHARACTER(1500) NOMDEL
      WRITE(NOMDEL,'(400(1H ))')
      LD=LCDIR(ND)
      LN=LEN_TRIM(HNOMEF)
      WRITE(NOMDEL,'(6H@DEL ",A<LD>,A<LN>,1H")')HCDIR(ND),HNOMEF
      LU=LD+LN+07
      CALL SYSTEMQQ(NOMDEL(01:LU))
      RETURN
      END

IFx  /fixed /c  x8.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.2.0 Build 20240602
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

x8.f90(11): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL.   [LEN_TRIM]
      LN=LEN_TRIM(HNOMEF)
------------------^
xfortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for x8.f90 (code 1)

 I spend a few minutes on xxxx.f90 and started chopping away routines from the bottom. The ICE melted when subroutine DEFILE  was deleted. I then deleted the routines before DEFILE and the unused modules. The 16 lines above still ICE but there appears another clue as the parsers seems to get lost on line  6. 

[andrew_4619]

SUBROUTINE DEFILE(ND,HNOMEF)
   CHARACTER(1000) HCDIR(30)
   CHARACTER(1500) NOMDEL
   WRITE(NOMDEL,'(6H@DEL ",A<LD>,A<LN>,1H")')HCDIR(ND),HNOMEF
END

ifx /c x9.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.2.0 Build 20240602
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

xfortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for x9.f90 (code 1)

For what it is worth a reduced reproducer. Using implicit typing (urgh) HNOMEF is type real. At line 4 it is being written us with a "A" character format using a non-standard <N> format feature, that is internal a mixed character and Hollerith format. Pretty awful really. Some basic code checking like check interfaces would expose that. The compiler should catch the mismatched types and not ICE though IMO.

Looking closer I suspect the format itself if causing the ICE, the double quote characters are in the hollerith strings and I think the compiler is getting lost. 

[Rv49]

Good morning andrew_4619:

In XXXX.F90 routine DEFILE is called once only at line 332 by this statement:

CALL DEFILE (01,'SELEZIONE_OUTPUT.CSV')

Routine DEFILE is sited in XXXX.F90 from line 795 to 816 both included: at line 803, then internal to the routine, there is this statement:

CHARACTER(   *) HNOMEF

Why this statement doesn't appear in your report of routine DEFILE ?

Really, HNOMEF in DEFILE is defined as a hollerith referring its size to the corresponding argument of CALL DEFILE in the main program.  In this call statement (line 332) HNOMEF is a constant by the hollerith point of view.

This feature is accepted by IFORT, why it's should not be accepted in IFX?

Anyway, I attempted to:

1) define HNOMEF in the main program as CHARACTER(0020)

2) before CALL DEFILE, add the statement HNOMEF='SELEZIONE_OUTPUT.CSV'

3) modify the call statement as CALL DEFILE(01,HNOMEF)

but compiling with the commandline IFX /fixed XXXX.F90 the ICE

xfortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for ELFO_DGS.F90 (code 1)

still is detected .

Thank you for your attention and best regards,

Rv49

[Rv49]

Excuse me, ELFO_DGS is the original name of XXXX

[Rv49]

The commandline has been IFX /fixed ELFO_DGS.F90

[andrew_4619 · Accepted solution]

Fixed is not relevant the line WRITE(NOMDEL,'(6H@DEL ",A<LD>,A<LN>,1H")')HCDIR(ND),HNOMEF causes the ICE irrespective of if HNOMEF is declared or not, that was my last note in the previous post.   If you write the format in a standard way it will compile. 

Or maybe just do something like:

NOMDEL = '@DEL "'//HCDIR(ND)(1:ld)//trim(HNOMEF)//'"'

[Rv49]

Hi andrew_4619,

I confirm you that substituting:

WRITE(NOMDEL,'(6H@DEL ",A<LD>,A<LN>,1H")')HCDIR(ND),HNOMEF

by
NOMDEL = '@DEL "'//HCDIR(ND)(1:LD)//TRIM(HNOMEF)//'"'

XXXX.F90 is succesfully compiled also in IFX generating  XXXX.EXE .

Please accept my compliments for your deep knowledge of the language, I didn't know such forms of writing into a string, practically assigning to it the sequence of n others avoiding to pass through a format.

Best regards, Rv49

[Devorah_H_Intel]

I was able to reproduce the issue internally. This case has now been escalated to compiler engineering for a fix. I will post an update when the fix is available. Thank you for reporting this to us, and thank you to @andrew_4619  for narrowing it down. 

[Ron_Green]

I will write up a bug report.  

As for why ifort can compile this while ifx gets the ICE:  the parsing of the code is the same in the compiler front ends - shared code.  But once the abstract syntax tree (AST) is created the code diverges.  ifx has to "lower" the AST to LLVM IR.  Ifort lowered to IL0.  Where I see this bug is in the IR we are passing down to LLVM.  We can fix this, I'll get it going.  

Andrew's workaround could be used.  Since the code for the upcoming October/Nov 2025.0.0 release is just past code freeze and initial builds, the next compiler that could potentially see a fix is 2025.1.0 and that we won't see until March/April 2025.  

[Ron_Green]

Looks like Devorah beat me to the bug report.  It's in good hands.

[Rv49]

Many thanks again to you, Devorah_H_Intel and andrew_4619 for the attention to this case.  Now I am asking: what does it mean exactly the deprecation of IFORT?  In any case will I be able to use IFORT on my computer also during the first months of 2025, simply not downloadig OneAPI 2025.0.0, and waiting the availability of OneAPI 2025.1.0 ?

Best regards to you, Devorah_H_Intel and andrew_4619

Rv49