IFX /Od produces EXE that aborts with access violation even though program is error-free

[mecej4]

Here is a cut-down reproducer that shows some peculiar behavior when compiled with IFX /Od on Windows. I am using the "Intel(R) 64, Version 2022.2.1 Build 20221101" version.

The program (link given below) runs with no error when compiled with Ifort, Gfortran, NAG, etc. It runs correctly even with IFX if /Od is not used, or if some of the Print statements in the program are commented out, or if the EQUIVALENCE between two integer variables is removed (this is easy to do with the small reproducer, but much more troublesome in the original test program, which is about 20,000 lines of Fortran 77).

Please note the puzzling line number of zero in the traceback:

S:\ALGO\ODEPACK\HYB\npol\Morn\pol\p2\tbed>ifx /Od tmdIfx.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2022.2.1 Build 20221101
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.33.31629.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:tmdIfx.exe
-debug
-pdb:tmdIfx.pdb
-subsystem:console
-incremental:no
tmdIfx.obj

S:\ALGO\ODEPACK\HYB\npol\Morn\pol\p2\tbed>tmdifx
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
tmdIfx.exe         00007FF793841CD8  MDM                        22  tmdIfx.f90
tmdIfx.exe         00007FF7938414AD  MD                         39  tmdIfx.f90
tmdIfx.exe         00007FF793841176  MD.t0p.t0p.t0p.t0           0  tmdIfx.f90
tmdIfx.exe         00007FF793841098  TMD                        12  tmdIfx.f90
tmdIfx.exe         00007FF7938422CE  Unknown               Unknown  Unknown
tmdIfx.exe         00007FF793844C84  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FF86E42244D  Unknown               Unknown  Unknown
ntdll.dll          00007FF86F9ADFB8  Unknown               Unknown  Unknown

[Ron_Green · Accepted solution]

Thanks for sending this example.

I confirmed the error in the 2022.2.1 compiler.

Then tested with the 2023.0.0 compiler which SHOULD be releasing soon, either later Dec 2022 or early Jan 2023.  No error with this compiler.  So a fix is on the way.  Between the compiler you have and this yet-to-be-released compiler there were a number of fixes for debug symbol creation.