ifort read file error and ifx internal compiler error for oneAPI 2023.0.0 for Modflow6 Software

[Scott_Boyce]

I attached a program called MODFLOW6 (mf6),

hosted at https://github.com/MODFLOW-USGS/modflow6

that does compile with ifort from oneAPI 2023.0.0 (2021.8.0 20221119), but when running the software causes read file errors that do not occur with previous versions of ifort or gfortran.

A single example is provided in the example folder to illustrate this problem. To run the example, the bash file, run_example.sh, calls the compiled executable and the appropriate input file. Note that this bash script is setup to run the mf-debug.nix, and if you want to test the release version, it will have to be modified to run mf6.nix as the program. Using older versions of ifort results in a successful completion of the program.

When the example problem is run, the following error message is triggered by the code:

#########################################################################

>>> mf6.nix  mfsim.nam

ERROR REPORT:

1. ERROR. "BEGIN" DETECTED BEFORE "END OPTIONS". "END OPTIONS" MUST BE USED
TO END OPTIONS.

UNIT ERROR REPORT:

1. ERROR OCCURRED WHILE READING FILE
'modflow6/example/mfsim.nam'

#########################################################################

which with all past versions of ifort (and all versions of gfortran) would successfully read the file and the simulation would complete successfully.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This same code also fails to compile with ifx from oneAPI 2023.0.0 (2023.0.0 20221201) with an internal compiler error. The following is the output from compiling on Lubuntu the code with the following arguments

ifx -O0 -g -debug -traceback -fpe0 -fp-model source -nologo -warn nousage -check bounds,pointers,stack,format,output_conversion,uninit -static -static-intel -qopenmp-link=static -static-libstdc++ -static-libgcc

#########################################################################

/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1f563ca]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1bef70e]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c55e52]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c55e26]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b6fb6c]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1be23f6]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c2bfc8]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c93141]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca1cc5]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c2b06d]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca13d9]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca6a30]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca19c2]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca104a]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b44bf6]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b445c9]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1d028ee]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f715789cd90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f715789ce40]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1982da9]

./src/Model/GroundWaterFlow/gwf3tvbase8.f90(373): 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.
bndElem => this%get_pointer_to_value(node, varName)
-------------------^
compilation aborted for ./src/Model/GroundWaterFlow/gwf3tvbase8.f90 (code 3)
make[1]: *** [makefile:726: make/obj_temp/debug_ifx/gwf3tvbase8.o] Error 3

#########################################################################

I attached a zip file of the project with the main source under the src folder, a makefile for compiling in Linux, for windows a solution file located at modflow6/msvs/mf6.sln, and input files are in the example folder.

There are two makefiles, the first is the one that comes with the github repository (located at modflow6/make/makefile). The second makefile is one that I setup for posting on here (located at modflow6/makefile) for ease for the Intel engineers to compile. I will explain next how to setup the second makefile.

The added makefile (located at modflow6/makefile) has a set of variables that control how the compiled variable is made. There are comments to explain what they do, but I will give a brief explanation:

#########################################################################
# Set to "RELEASE" for -02 compilation, "DEBUG" for -O0 -g -debug -traceback compilation

# RELEASE makes "bin/mf6.nix"; and DEBUG makes "bin/mf6-debug.nix"
CONFIG := DEBUG
#
# Set to "INTEL" to indicate that oneAPI is used
COMPILER := INTEL
#
# Set to "ifort" or "ifx" to indicate the compiler command invoked
F90 := ifx
#
#
# Set to "YES" to include static flags, otherwise set to "NO"
STATIC := YES

#########################################################################

For testing on here I would compile with

F90 := ifx

and

F90 := ifort

to evaluate the two issues posted here.

If you want to adjust the specific flags used in the compiler by changing the variable:

F90FlagsIntel

which is located within in an ifeq ($(CFG), DEBUG) that sets it to values based on if CONFIG := RELEASE and CONFIG := DEBUG.

#########################################################################

These same problems occur on Windows 11 and Visual Studio 2019 for ifort and ifx.

For the case of ifx, we would like to switch to this eventually, but we need to be able to successfully compile an executable and pass all our unit tests.

Thanks all for the help and support.

[Barbara_P_Intel]

I'm investigating this.

For the runtime error:

• Can you please confirm that this app ran okay when compiled with ifort 2021.7.0?
• What is the error you get from the Fortran compiler when you run this? The message you reported comes from your app.

For the internal compiler error (ICE), I worked with it and narrowed the number of lines of code to reproduce the problem quite a bit. The issue is a compiler problem with derived types. I submitted a bug report on your behalf, CMPLRLLVM-44872. I'll let you know when it's fixed.

[Scott_Boyce]

Yes, so the software runs fine with earlier versions of ifort (such as, 2021.7) and with gfortran, but with the 2021.8 ifort version something happens when parsing the command argument flags and opening/reading the main input file (mfsim.nam).

If you run the example, with a binary compiled with an older ifort will result in a successful completion of the program, while running with 2021.8 results in the main input file failing to read part of the input file. Rather than having a fortran error occur the code is raising its own error message. I think something changed with the new release that is causing the file i/o issues in the software.

[Barbara_P_Intel]

I understand that it is the app's error message. What is the READ error that the app is handling?

[Scott_Boyce]

I think I isolated the problem for ifort (ifx still does not compile).

It is failing when using a combination of the "subroutine get_line(lun, line, iostat)" with "backspace(lun)"

when reading the first couple of input lines.

The call stack is:

subroutine simulation_cr()                                                   -> SimulationCreate.f90

subroutine read_simulation_namefile(namfile)                                 -> SimulationCreate.f90

subroutine options_create()                                                  -> SimulationCreate.f90

subroutine GetBlock(this, blockName, isFound, ierr, supportOpenClose, &
                    blockRequired, blockNameFound)                           -> InputOutput.f90

subroutine uget_block(iin, iout, ctag, ierr, isfound, lloc, line, iuext, &
                       blockRequired, supportopenclose)                      -> InputOutput.f90

subroutine u9rdcom(iin, iout, line, ierr)  -> InputOutput.f90

subroutine get_line(lun, line, iostat)     -> InputOutput.f90

I wrote up a simple example that creates this problem and attached it here.

What it does is make a file that is:

-------------------
line 1          
line    2       
line       3    
line          4 
-------------------

and then I reopen that file for read and use get_line to read the first two lines, then backspace, then get_line again.

The expected output should be "line    2" repeated twice, but instead it writes "line         3"

[Barbara_P_Intel]

Thank you for taking the time to create such a nice reproducer! I see that it is a regression. I filed another bug for you, CMPLRLIBS-34350. I'll keep you posted on its progress to fix.

[Scott_Boyce]

Great to hear about the bug fix being in the works.

I did try oneAPI 2023.1 April download but I still get the same compiler error message when compiling with ifx.

[Scott_Boyce]

Also, it does compile with ifort, but still has the same error when running the examples (reported earliar with the get_line code).

[Barbara_P_Intel]

The ICE is fixed in the compiler that will be released around mid-year 2023.

Correct. No fix yet for the get_line issue.