Guidance for tracking down xfortcom internal compiler error

Compilers Intel
1

Just installed the latest version of ifx on my Windows 10 machine with extended support. My very mature optical engineering application (99.9% f95) compiles fine with optimizations turned off (/Od) but not surprising runs 4x slower than an optimized gfortran version. Any other level of optimization generates an xfortcom internal error in one of the larger (out of a couple dozen) source files. Any strategy for determining the specific statement or statements that’s tripping up the compiler. At this point I wish I could go back to the last version of classic ifort but it’s no longer available.

1 Like
2

I think the best way to do this is to start isolating that file as much as possible. Comment things out in an increasingly aggressive way. I usually like commenting out everything and leaving out stubs so that the code can actually link. If you can compile that file standalone that helps a lot too.

Once you have commented things out you can start reintroducing one by one to try to find what statement is breaking the compiler. If you have access to other versions of the ifx compiler or another compilers outside gfortran that could also help narrow things down.

3

Just like @jorgeg said, isolating the code is probably the way to go.

But instead of commenting out, use preprocessing groups, to avoid messing thing up with regards to your actual comments. Say:

function myfunc(x) result(y)
    integer :: y
    integer, intent(in) :: x
#if false
    ! your actual code goes here
    ...
contains
    subroutine contained
        ...
    end subroutine
    ...
#endif
end function
4

Also, try a different compiler if available. Don’t know if LLVM flang is available on Windows, but I would try that since ifx is also based on LLVM. I don’t think the other LLVM based compilers (classic flang) from AMD or NVIDIA have a Windows version so your only other option is probably the latest available gfortran.

5

There is an flang-new version for Windows, so that is also a possibility. Careful though, there is flang “classic” and flang “new”. The latter can be found at Welcome to Flang’s documentation — The Flang Compiler.

6

Some people have an old copy of IFORT Installer stacked away. It is easy to ask. Plus if you had it installed then updating to IFX does not remove IFORT. I have been using G++, it is not speed that one is interested in it is the difficulty of using any form of good IDE. I am back to the old batch file and use MSVS to edit the main.cpp. Plus the code references time.h, there are 107 copies of time in 29 different versions.

7

Thanks for all the replies but I was hoping maybe there was trick to get ifx itself to give me a clue so I wouldn’t have to drudge thru manually trimming down my code to isolate the bug. Anyway it took a while but I finally found it in a routine that defined an argumentless statement function that was then used in its internal routines (after CONTAINS). Not a best programming practice today but I’ve been writing Fortran since the 70’s and like simple statement functions because they don’t require the additional boiler plate of an internal routine.

I also took the other suggestions and compiled my application with gfortran 15, flang 20, and ifx 25 on an Ubuntu machine (ifx tripped over the same internal compiler error as on Windows), all using “fast” optimization. In subsequent benchmarks the LLVM versions (flang and ifx) were essentially tied but (not surprising to me) gfortran versions on the order of 20% faster (single and OpenMP multiple threads).