Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28385 Discussions

Catastrophic error compiling Fortran project with oneAPI 2023.0.0

Scott_Boyce
New Contributor I
5,593 Views

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.

0 Kudos
33 Replies
Ron_Green
Moderator
1,227 Views

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 

 

 

0 Kudos
Scott_Boyce
New Contributor I
1,135 Views

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.

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,118 Views

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

Scott_Boyce
New Contributor I
1,051 Views

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.

 

0 Kudos
Ron_Green
Moderator
1,018 Views

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
New Contributor I
1,003 Views

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)

 

 

0 Kudos
Scott_Boyce
New Contributor I
943 Views

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

0 Kudos
Ron_Green
Moderator
928 Views

@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.

0 Kudos
Scott_Boyce
New Contributor I
926 Views

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

 

 

 

 

 

 

 

 

0 Kudos
Ron_Green
Moderator
637 Views

This bug is fixed in the 2023.2.0 release.


0 Kudos
Ron_Green
Moderator
635 Views

This bug is fixed in 2023.2.0


0 Kudos
Scott_Boyce
New Contributor I
635 Views

Thanks, I was able to compile and run the software using both ifort and ifx.

Do you know when the ifx will run as fast as ifort? I would like to switch to it, but it still rounds about 10% slower than ifort.

Another question, is there a compiler flag that will produce the same solution between the two compilers? My test cases only produced the same results up to about 5 digits.

0 Kudos
Mark_Lewy
Valued Contributor I
603 Views

If you haven't read this already, look at https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-ifort-to-ifx.html.  We found that using the precise floating point model instead of the fast model would improve consistency between ifort and ifx (and also between Windows and Linux); the performance degradation was minimal.

0 Kudos
Reply