ICE in debug mode and compiler hang

[uha]

I have the following code that gives an ICE with ifx (ok in ifort):

MODULE MWmSetio
  implicit none
  public
  save
  contains

LOGICAL FUNCTION WM1200(nszmax, &
    n3dgrid,zlower,con,conz)
  implicit none
  integer nszmax
  integer n3dgrid(nszmax)
  real zlower(nszmax), &
    con(nszmax),conz(nszmax)
  WM1200=.false.
  if(.not.(WM1201(nszmax,n3dgrid)))goto 9999
  WM1200=.true.
 9999 continue
end

LOGICAL FUNCTION WM1201(nmax,n3dgrid)
  implicit none
  integer ilay,nmax
  integer n3dgrid(nmax)
  real :: zlower(nmax),hsz0(nmax),con(nmax), &
    conz(nmax),sart(nmax),sfree(nmax)
  logical WM1201a
  integer itype,i,nskip,idum
  real :: dum(1)=(/0.0/)
  WM1201=.false.
  itype=-1201
  WM1201=.true.
  goto 9999
! ----------------------------------------------------------------------
  ENTRY WM1201a(nmax,ilay,n3dgrid)
! ----------------------------------------------------------------------
  WM1201a=.false.
  itype=-1201
  WM1201a=.true.
 9999 continue
end

END MODULE MWmSetio

xfortcom: Fatal: There has been an internal compiler error (C0000005).

Visual Studio version is 2022 (17.8.6), oneApi is 2024.0.2

This happens in a debug build only and works in release. Also, when not producing debug information the build succeeds. Another way: remove all function arguments, again it will build (I have not tried if it is one specific argument type like arrays).

Yes, "entry" is an eyesore - hundreds of these in the original 6k line file, so I cannot currently do anything about that.

I tried building this one project (out of ~30) with ifort instead of ifx. Building works, but I get an infinite debugger hang ("Debug operation is taking longer than expected") - at least I now suspect it is that combination, but cannot reproduce it in a small sln.

Is there any workaround for the ICE other than not producing debug info?

[andrew_4619]

 I had a play with your code,  it seems related the ENTRY and use in a MODULE I feel. If you delete function WM1200 of compiles, if you have WM1200 after WM1201 it compiles. If you delete the ENTRY line it compiles and if you remove the module and have external functions (and add a function type declaration) it compiles.

I can't see any easy workaround other than the obvious solution of undertaking a large project to get rid of ENTRY which you need to do if the code has a long future ...... but yes I understand!

[Ron_Green]

We fixed another bug related to ENTRY lately.  But alas, this is on another code path.  As @andrew_4619 found it's in the interaction of the ENTRY inside the module.   I'll get a bug report on this an assign to the developer who was just in this section of code (ENTRY). 

Thank you for finding this and bringing it to our attention.  

[Ron_Green]

Probably not helpful, but instead of /debug:full or :all use /debug:minimal

this will allow a traceback for a crash but will not allow you to use the VS debugger for anything useful (no symbols).

[uha]

Thanks Ron and Andrew for looking into this and the additional details. This part of our code is very stable, which must be why it never got updated. It also means I hardly ever need to debug it, so temporarily not producing full debug info is not a problem.

[Devorah_H_Intel]

This issue has been fixed in the recently released Intel Fortran Compiler, available for download as part of Intel HPC Toolkit 2024.2.1