oneAPI 2024.1.0 Internal Compiler Error with IFX

[Cameron]

What is the best way to approach these internal compiler errors when converting from ifort to ifx? I've pasted the traceback below but I haven't been able to pinpoint where to really begin looking other than around line 152.

The subroutine here on line 152 in this error has multiple entry points, multiple goto statements, and a contains clause. If I were writing from scratch, I would have this file designated as a module with subroutines for each of these entry points.

#0 0x00007ff70456046a (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x112046a)
#1 0x00007ff70455327a (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x111327a)
#2 0x00007ff7044a7df7 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x1067df7)
#3 0x00007ff7044f3c1c (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x10b3c1c)
#4 0x00007ff7044f2ef7 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x10b2ef7)
#5 0x00007ff704538313 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x10f8313)
#6 0x00007ff70453a4a6 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x10fa4a6)
#7 0x00007ff704537284 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x10f7284)
#8 0x00007ff70453703d (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x10f703d)
#9 0x00007ff704477131 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x1037131)
#10 0x00007ff704476b90 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x1036b90)
#11 0x00007ff703454a8e (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0x14a8e)
#12 0x00007ff7042a8518 (C:\PROGRA~2\Intel\oneAPI\compiler\2024.1\bin\compiler\xfortcom.exe+0xe68518)
#13 0x00007ff93d3f257d (C:\Windows\System32\KERNEL32.DLL+0x1257d)
#14 0x00007ff93e88aa48 (C:\Windows\SYSTEM32\ntdll.dll+0x5aa48)


C:\dev\dir\file.f90(152): error #5623: **Internal compiler error: internal abort** 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.


ifx: error #10298: problem during post processing of parallel object compilation

[Barbara_P_Intel]

What compiler options are you using? Sometimes the ICE (internal compiler error) goes away when compiling with /Od.

ifx should not do that. Please post a small reproducer so we can file a bug and get that fixed!

As another workaround you can mix and match object files and .mod files between ifx and ifort as long as you aren't compiling with /Qipo.

[Cameron]

Our debug configuration builds are set to use /Od for the optimization level. Our release configuration is set to the default to maximize speed, but I have not been able to try release builds on IFX yet.

The compiler options I am seeing from our project file are these (minus the /I flags since they contain our internal project names):

/nologo
/debug:full
/MP
/Od
/assume:buffered_io
/DDLLE
/extend-source:132
/noaltparam
/Qopenmp
/standard-semantics
/fpscomp:logicals
/Qdiag-disable:11073,10448
/debug-parameters:all
/warn:declarations
/warn:externals
/warn:unused
/warn:truncated_source
/warn:uncalled
/Qauto
/iface:cvf
/module:"x64\Debug\\"
/object:"x64\Debug\\"
/traceback
/check:bounds
/check:uninit
/check:format
/check:output_conversion
/check:stack
/libs:dll
/threads
/dbglibs
/c
/dll
/Qip
/Qprec
/QxAVX
/assume:nofpe_summary

[Barbara_P_Intel]

So much for the easy fix.

Please post a small reproducer.

[Cameron]

Attached example.f90 which yields an internal compiler error; this is a very simplified version of the file that produces the error in our build.

If you comment out line 30, the error goes away. Additionally, if the entry point is set to take iarray as an argument this issue also goes away for me.

Code in case file is deleted:

    subroutine outer_sub(nstarg, dimarg, errarg)

        implicit none

        integer nstarg, dimarg, retarg, errarg, &
                iarray(dimarg, nstarg)

        integer, parameter :: nstr = 16

        errarg = 0
        return

    entry get_count(nstarg, dimarg, errarg, retarg)

        errarg = 0
        retarg = 0
        return

    contains

    subroutine my_contained_sub

        integer :: m, n

        retarg = 0

        select case (errarg)

            case (1)
                iarray(m, n) = 1
                retarg = 1
            case (2)
                retarg = 1

        end select

    end subroutine my_contained_sub

    end subroutine outer_sub

[Barbara_P_Intel]

Thanks for the reproducer, @Cameron!

It still ICEs (internal compiler error) in the preview version of 2024.2. I filed a bug report, CMPLRLLVM-58122. We'll let you know when it's fixed.

[VianneyDelb]

I have the same issue on functions having many entrypoint. The compilation passes when I comment all ENTRY statements.

[Devorah_H_Intel]

If you have a short test case - I will test it internally to ensure it is fixed. 

---

@VianneyDelb wrote:

I have the same issue on functions having many entrypoint. The compilation passes when I comment all ENTRY statements.

---

[Devorah_H_Intel]

The issue has been fixed; the fix will be available in the future compiler release. 

[Cameron]

That is good to hear. Is there an ETA on the next release or possibility of obtaining a beta/release candidate of the compiler? I am trying to get our codebase to be IFX compliant by end of year.

[Devorah_H_Intel]

---

@Cameron wrote:

That is good to hear. Is there an ETA on the next release or possibility of obtaining a beta/release candidate of the compiler? I am trying to get our codebase to be IFX compliant by end of year.

---

Since you have Priority support, I have opened a case for you to address your questions and requests. Please check for email notifications from Intel Compiler support (me). The short answer - is a few months, and yes, we can provide and engineering compiler for testing to Priority support customers.