Catastrophic error compiling Fortran project with oneAPI 2023.0.0

[Scott_Boyce]

Hi All,

I am a developer for a Fortran project called MODFLOW-OWHM. After updating my oneAPI from 2022.1.1 to 2023.0.0, I am now getting a:

catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. 

message.

The project has a Fortran only option and I am compiling with the Intel Fortran Compiler Classic to create this error. In particular, Intel Fortran Compiler Classic (ifort) 2021.7.1 compiles fine, while 2021.8.0 raises the error.

I get the same error, but for a different file, if I try the Intel Fortran Compiler (ifx) 2023.0.0, but I have never been able to compile with that (previously ifx would raise errors saying feature not yet supported, but now it just says catastrophic error).

The source code is hosted at:

https://code.usgs.gov/modflow/mf-owhm 

(gitlab source repository)

with the main source under the src folder, a makefile for compiling in linux, and for windows a solution file located at ide/visual_studio/OneWater_Project.sln

For ifort, I get the same error on both linux and windows with the error happening in src/modflow_base/wel8.f90

I am using Windows Visual Studio 2019, my debug compliation, and the problem file has the following message:

ifort /nologo /debug:full /Od /assume:nocc_omp /Qdiag-error-limit:10 /Qdiag-disable:6717 /warn:declarations /warn:unused /warn:ignore_loc /warn:noalignments /warn:uncalled /warn:interfaces /real-size:64 /fpe:0 /fp:source /Qfp-stack-check /module:"obj\vs_mf-owhm_Debug_x64\\" /object:"obj\vs_mf-owhm_Debug_x64\\" /Fd"obj\vs_mf-owhm_Debug_x64\vc160.pdb" /traceback /check:pointer /check:bounds /check:shape /check:uninit /check:format /check:stack /libs:static /threads /dbglibs /c /Qlocation,link,"Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64" /Qm64 "src\modflow_base\wel8.f90"
fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for src\modflow_base\wel8.f90 (code 1)

The Linux error says something similar:

/src/modflow_base/wel8.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** 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.
compilation aborted for ./src/modflow_base/wel8.f90 (code 1)
make[1]: *** [makefile:756: obj/debug_ifort/wel8.o] Error 1

My office has several licenses to the intel compilers, but I do not have access to the intel accounts for posting support requests.

The code can be obtained from the gitlab repo, or I attached it here (I just quickly carved out code and zipped it up).

Any help with this would be greatly appreciated.

[Ron_Green]

Scott, our latest compilers are aborting on a coding error.  For my purposes to track the bug I'll just comment out the offending DEALLOCATE.  It's in array_data_types_instruction() line 3015

ifx   array_data_types_instruction.f90

./src/bif_lib/types_and_containers/array_data_types_instruction.f90(3015): error #5585: A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure.
            DEALLOCATE(LAC)
------------^
compilation aborted for ./src/bif_lib/types_and_containers/array_data_types_instruction.f90 (code 1)
make[1]: *** [makefile:756: obj/release_ifx/array_data_types_instruction.o] Error 1

I found some allocates also.  Perhaps BUILD_COMPRESSED_LOCATION_STORAGE_ALOC should not be declared PURE.  I'll try that instead to get past the coding issue

sub declaration

2934   PURE SUBROUTINE BUILD_COMPRESSED_LOCATION_STORAGE_ALOC(LAC, ARR, HAS_ZERO, ID)
2935     CLASS (COMPRESSED_LOCATION_STORAGE),DIMENSION(:),ALLOCATABLE, INTENT(INOUT):: LAC
2936     INTEGER, DIMENSION(:,:),                          CONTIGUOUS, INTENT(IN   ):: ARR
2937     LOGICAL,                                            OPTIONAL, INTENT(IN   ):: HAS_ZERO
2938     INTEGER, DIMENSION(:),ALLOCATABLE,                  OPTIONAL, INTENT(INOUT):: ID

and offending lines

3013     IF(ALLOCATED(LAC)) THEN
3014         IF(SIZE(LAC) /= N) THEN
3015             DEALLOCATE(LAC)
3016               ALLOCATE(LAC(N))
3017         END IF
3018     ELSE
3019         ALLOCATE(LAC(N))
3020     END IF 

[Scott_Boyce]

Thanks for looking into it. That is interesting about deallocate.

So you cannot have pure and deallocate something as CLASS?

I looked at that routine and I think its one that is not used by any derived procedure (it is used to make a COMPRESSED_LOCATION_STORAGE array type).

so I could change:

PURE SUBROUTINE BUILD_COMPRESSED_LOCATION_STORAGE_ALOC(LAC, ARR, HAS_ZERO, ID)
CLASS (COMPRESSED_LOCATION_STORAGE),DIMENSION(:),ALLOCATABLE, INTENT(INOUT):: LAC

to swap CLASS for TYPE

PURE SUBROUTINE BUILD_COMPRESSED_LOCATION_STORAGE_ALOC(LAC, ARR, HAS_ZERO, ID)
TYPE (COMPRESSED_LOCATION_STORAGE),DIMENSION(:),ALLOCATABLE, INTENT(INOUT):: LAC

I think I originally had it as a derived procedure for the COMPRESSED_LOCATION_STORAGE  type, but it was not allowed so I made it a standalone routine and never changed the CLASS to TYPE.

[Steve_Lionel]

C1596 A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure.

[Scott_Boyce]

I fixed that as well as a few other minor bugs and changed that CLASS to TYPE in BUILD_COMPRESSED_LOCATION_STORAGE_ALOC.

I attached the most current version of the MF-OWHM code, which has a number of changes in BiF_LIB.

I also attached the full BiF library (only a subset of BiF is used in MF-OWHM).

The code repository of BiF is https://code.usgs.gov/fortran/bif

Thanks again for working on this.

[Ron_Green]

Bug ID is CMPLRLLVM-46123. I was able to get this to a single source file, 395 lines, with no other sources needed, and ICE for just 'ifx -c repro600.f90'

As Steve said, this is a tremendous amount of work to take the deep USE nests and isolate it down. I think I could maybe get it smaller, but these complex ones are touchy - remove too much and it compiles w/o ICE. So I left it at 395 lines. A couple of developers are on it, and finding a null pointer return in a middle end function. Which is progress.

This one traced all the way back to bif_lib/io and the type CHARACTER_TYPE_ARRAY and CHARACTER_TYPE. So progress. I'll keep you updated.

[Scott_Boyce]

Thanks, let me know if there is anything I can do to help out.

If I recall, gfortran had a lot of issues with my use of CH%MAX_LEN() for the CHARACTER_TYPE_ARRAY type. I had originally used to create a stack character variable (CHARACTER(len=CH%MAX_LEN():: CHAR) but I had to refactor it to a block statement. That refactored code is located in the file array_data_types_instruction.f90 under the function:

PURE FUNCTION COUNT_NOCASE_CHARACTER_TYPE_ARRAY(CH, STR, IGNORE_CASE) RESULT(CNT)

[Scott_Boyce]

I just wanted to make sure that this is still on the todo list for a future fix.

I just installed oneAPI 2023.1, but I still get the same errors for both ifort and ifx.

Also, I recently got a new computer, is there a way to get the older version of ifort that can compile my code project. The one I have on my older computer that compiles the code fine is oneAPI 2022.2.1

[Ron_Green]

@Scott_Boyce  Great timing on this question:  we've had 3 developers working on this off and on for several weeks.  A fix just got tested yesterday.  I confirmed the fix with the overnight build of ifx.  It was non-trivial, the fix touched important data structures and our processing of variable references in 3 key source files.

Our code freeze for the 2023.2.0 release is coming up in about 2 weeks.  I fully expect this fix will be in that build but I will confirm with the early builds of 2023.2.0 to insure it is in the next release.

[Scott_Boyce]

That is excellent news and thanks for working at it (I know how it goes when minor problems snowball into major efforts).

You are more than welcome to use the code as part of the tests for releases.

https://code.usgs.gov/modflow/mf-owhm

which is also dependent upon a subset of this library:

https://code.usgs.gov/fortran/bif

Another major software project (have it listed in another forum post) that would be good to add to testing is:

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