oneAPI 2022.3 - There has been an internal compiler error (C0000005)

[Cameron]

After upgrading to the new oneAPI 2022.3, I am getting a strange compilation error for one of my *.for files that seem to compile fine with earlier versions of IVF: fortcom: Fatal: There has been an internal compiler error (C0000005). ifort: error #10298: problem during post processing of parallel object compilation Is there anything I can turn on to provide better insight as to what may be going on? I have been trying to recreate a simple Visual Studio solution that recreates the problem, but have been unable to do so. For reference (minus sensitive names) this is the statement that yields that error: IF (ALLOCATED(SOMEARR)) DEALLOCATE(SOMEARR) SOMEARR is defined like this in another module: type(custom_type), dimension(:), allocatable :: somearr

[Steve_Lionel]

The error message mentioning parallel compilation reminds me of an issue I haven't heard about in years. What happens here is that in a multi-file project, the build system does compiles in parallel (if dependencies are met). Sometimes a virus checker or other outside program temporarily locks new files, and this causes problems for the build system. It's possible that the new version introduced a bug here, however. Something is getting an access violation in the post-compile step.

The easy workaround may be to turn off parallel builds. Set project property Fortran > General > Multiprocessor compilation to No and see if that helps.

Is this error reproducible every time? If so, a bug is more likely.

[Cameron]

Hi Steve,

Apologies for the bad formatting. My community account had some puzzling issues, and I wasn't able to reply until now. Support has helped sort it out though now.

This bug is reproduceable every time on my end during a build. The first thing I tried doing was disabling the /MP flag for the project that contains this file, but this error remains without any additional information:

fortcom: Fatal: There has been an internal compiler error (C0000005).

[jimdempseyatthecove]

FWIW in the AV I use, I disable scanning of my development output directories. This eliminates (potential) "file in use" errors in the build system.

Also, I suggest you experiment by turning off IPO. Try first by turning off all IPO (inter-file and intra-file). If that works, then you can experiment on a file-by-file basis. Often problems (?bugs?) like this can be managed with little effect on the performance of the application. If you can construct a reproducer for Intel to use for bug-fix, it would help their development team. Though IPO issues are likely not representable by a simple reproducer.

Jim Dempsey

[Cameron]

This statement yields internal compiler error:

IF (ALLOCATED(SOMEARR)) DEALLOCATE(SOMEARR)

SOMEARR is defined like this in another module:

type(custom_type), dimension(:), allocatable :: somearr

[Ron_Green]

From the code fragment it's hard to say.

I'd try some experiments, breaking up the IF to multiple lines and see if and where it fails.

Is it the IF

Is it the ALLOCATED call

Is it the DEALLOCATE call.

!..new var
logical :: al_ocated
...etc..
!..comment IF (ALLOCATED(SOMEARR)) DEALLOCATE(SOMEARR)
al_ocated = ALLOCATED(SOMEARR)
!..commentIF (al_ocated) then
!..comment   DEALLOCATE(SOMEARR)
!..commentEND IF

and also try

!..comment IF (ALLOCATED(SOMEARR)) DEALLOCATE(SOMEARR)
!..comment al_ocated = ALLOCATED(SOMEARR)
IF (al_ocated) then
   DEALLOCATE(SOMEARR)
END IF

and finally the split up statment

!..comment IF (ALLOCATED(SOMEARR)) DEALLOCATE(SOMEARR)
al_ocated = ALLOCATED(SOMEARR)
IF (al_ocated) then
   DEALLOCATE(SOMEARR)
END IF

[Cameron]

I've tried splitting the code up (in my actual source the subroutine is just a bunch of IF (ALLOCATED(..)) DEALLOCATE(..) calls). Here is what I found:

This works fine, no compilation errors:

logical al_olcated
al_located = allocated(somearr)

Adding a call to deallocate(), however, immediately produces the same internal compiler error:

logical al_olcated

al_located = allocated(somearr)

if (al_located) then
    deallocate(somearr)
end if

Moving the deallocation call to anywhere in the subroutine yields the same error. Interestingly, if I add duplicated USE statement, this error goes away. This subroutine is included within a contains statement (rough outline below):

subroutine foo
!...
use my_module
!...
implicit none
!...

contains

subroutine clear_arr

use my_module

logical al_located

al_located = allocated(somearr)
if (al_located) then
    deallocate(somearr)
end if

end subroutine clear_arr

end subroutine foo

.

[jimdempseyatthecove]

Does the custom_type have contained procedures?

The reason I ask is, that while the contained procedure (clear_arr) would have access to the variable (somearr) in foo, that there may be some subtly relating to access to the UDT contained procedure (that is corrected with the "extra" use my_module).

In any event, you have found a work around.

Thanks for your post.

Jim Dempsey

[Ron_Green]

we'll have to keep an eye out for this error.  Hopefully someone else might hit it and have a project they can share.

But I am glad you have a workaround.  I hope someday we can get to the bottom of this.  

[JohnNichols]

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER, PARAMETER :: dp = selected_real_kind(15, 307)
    REAL (KIND=dp) :: g = 9.806, pi = 3.14159265D0

    TYPE snode
        INTEGER id
        INTEGER :: tank = -1
        INTEGER :: zone = 0
        REAL (KIND=dp) x
        REAL (KIND=dp) y
        REAL (KIND=dp) e
        REAL (KIND=dp) c0
        REAL (KIND=dp) qbase
        REAL (KIND=dp) cs
        REAL (KIND=dp) h
        REAL (KIND=dp) c
        REAL (KIND=dp) inddemand
        REAL (KIND=dp) parkdemand
        REAL (KIND=dp) leakdemand
        REAL (KIND=dp) resdemand
        REAL (KIND=dp) dumc
        REAL (KIND=dp) q
    END TYPE
CONTAINS

    ! Adding RECURSIVE to the SUBROUTINE statement does not change
    ! the buggy behavior of the program.
    RECURSIVE SUBROUTINE S1(I)
    IMPLICIT NONE (TYPE, EXTERNAL)
    INTEGER :: I

    ! Adding SAVE to the following declaration solves all the issues.
    INTEGER :: J
    WRITE(*, *) I
    IF (I == 1) THEN
        J = 2
    ELSE
        J = J + I
    END IF
    IF (J > 5) STOP
    CALL S1(J)
    END SUBROUTINE S1

END MODULE M


PROGRAM P
USE M
IMPLICIT NONE (TYPE, EXTERNAL)

type(snode), allocatable :: somearr(:)
logical al_located
integer err



allocate(somearr(12), STAT = err)

write(*,*)err
al_located = allocated(somearr)
write(*,*)al_located
IF (ALLOCATED(SOMEARR)) DEALLOCATE(SOMEARR)
! For the next two lines...
!     - Commenting the call to S1 leads to proper execution of S2.
!     - Commenting the call to S2 leads to buggy behavior of S1.
!     - Having both calls uncommented lead to buggy behavior of S1 and S2.
CALL S1(1)
CALL S2(1)

CONTAINS

    RECURSIVE SUBROUTINE S2(I)
    IMPLICIT NONE (TYPE, EXTERNAL)
    INTEGER, INTENT(IN) :: I
    INTEGER :: J
    WRITE(*, *) I
    IF (I == 1) THEN
        J = 2
    ELSE
        J = J + I
    END IF
    IF (J > 5) STOP
    CALL S2(J)
    END SUBROUTINE S2

END PROGRAM P

Why is somearr undefined if it was allocated correctly as shown below

[andrew_4619]

John, that is probably a VS debugger bug, is is vs2022? Such things have been reported for a while.

[JohnNichols]

I cannot get the oneapi latest Fortran to work on VS 2019, so yes it it vs 2022.   I was interested in the code from @Cameron  as I use a lot of allocates, makes life much simpler, interesting that it fails to show on being allocated.