Module variables imported with 'only' get no debug symbols

Developer Software Tools Intel® Fortran Compiler
1

Hi,

In a routine that does use some_module, only: var, the plain name can’t be evaluated in the debugger (“Undefined variable”). The module-qualified name works: some_module::var. ifort resolved the plain name.

Environment

  • ifx 2026.1.1 (Intel(R) Fortran 26.0-1156 / DPC++/C++ Compiler 2026.1.1 20260724)
  • Visual Studio 2026 Professional, Windows 11 x64, Debug build, /Od /Z7 /debug:full, linked with /debug
  • Intel Fortran Expression Evaluator 2.0.0 is installed.

Reproducer: three files

m_vars.f90

module gtm
  implicit none
  integer :: ntank = 0
  real, allocatable :: tankgiip(:)
end module gtm

hdf_demo.f90

module hdf_demo
contains
  subroutine settank(it)
    use gtm, only: tankgiip, ntank
    implicit none
    integer, intent(in) :: it
    real :: x
    x = tankgiip(it) + real(ntank)      ! <- breakpoint here, then evaluate: tankgiip, ntank
    tankgiip(it) = x
  end subroutine settank
end module hdf_demo

main.f90

program demo
  use gtm, only: tankgiip, ntank
  use hdf_demo, only: settank
  implicit none
  ntank = 7
  allocate(tankgiip(ntank)); tankgiip = 1.0
  call settank(3)
  print *, tankgiip(1)
end program demo

Build

ifx /Od /Z7 /debug:full m_vars.f90 hdf_demo.f90 main.f90 /link /debug

Expected: tankgiip and ntank can be evaluated at the breakpoint.
Actual: tankgiip gives Undefined variable, while gtm::tankgiip works.

What I found in the debug info. The object file for hdf_demo.f90 has no S_LDATA32 record for tankgiip or ntank in settank.

The records appear if any routine in the same file imports the module with no ONLY list. Adding this to hdf_demo.f90, never called, is enough:

  subroutine never_called()
    use gtm                  ! whole-module USE
    implicit none
  end subroutine never_called

Then settank gets S_LDATA32 NTANK and S_LDATA32 TANKGIIP.

I couldn’t find any compile options which changes this.

Thanks

2

As someone who ONLY uses use ONLY these problems hurt productivity. This problem has been around since IFX was launched and has been reported many times. It would be nice to hear from Intel to see if there is any prospect of a fix or if any work is ongoing. The other issue that causes problems is when stepping through code in debug the carrot jumps around in nonsensical ways as it seem the line numbers in the code generated often do not match up with the code. It is particularly irksome when you appear to step into code that logic dictates should not be entered (e.g. and If construct),

3

I totally agree with Andrew. This debugging issue in ifx is really annoying. The debugger sometimes jumps randomly through the code and goes into branches that are not executed. I still do all my debugging with ifort, ifx is not reliable at all.

4

The other issue that causes problems is when stepping through code in debug the carrot jumps around in nonsensical ways as it seem the line numbers in the code generated often do not match up with the code. It is particularly irksome when you appear to step into code that logic dictates should not be entered

Yes, I get this too. It’s very annoying. Sometimes it’s the inverse too where I’ll put a breakpoint inside a condition I know with 100% certainty will be entered, and it just never does.