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

[Jarzebski__Pawel]

Hi,

I faced following problem. When I updated to the Intel Compiler ver.18.0.1.156. Some of my programs stoped to compile. I investigated problem and I got minimal example:

module module1
  implicit none
  
TYPE, PUBLIC :: typeName
    INTEGER, ALLOCATABLE, DIMENSION(:) :: row, ptr
END TYPE

contains
    subroutine sub1(outmat)
      type(typeName), target, intent(inout) :: outmat
      integer :: i, j, k

      do i = 1, k
         do j = j, outmat%ptr(i+1)-1
            if(outmat%row(j).lt.i) cycle
            outmat%row(k) = j
         end do
         j = outmat%ptr(i+1)
      end do
   end subroutine sub1
end module module1

In debug mode this code compiles. In Release mode this code does not compile with an error as in title of the topic. As workaround I used additional "start" variable:

module module1
  implicit none
  
TYPE, PUBLIC :: typeName
    INTEGER, ALLOCATABLE, DIMENSION(:) :: row, ptr
END TYPE

contains
    subroutine sub1(outmat)
      type(typeName), target, intent(inout) :: outmat
      integer :: i, j, k,start

      do i = 1, k
         do j = start, outmat%ptr(i+1)-1
            if(outmat%row(j).lt.i) cycle
            outmat%row(k) = j
         end do
         start = outmat%ptr(i+1)
      end do
   end subroutine sub1
end module module1

This code compiles in both modes Debug and Release.

Let me know what is the problem.

[Arjen_Markus]

An internal compiler error is always a problem of the compiler itself, whatever program you offer it.

Introducing an extra variable merely means that you circumvent the problem in the compiler. It does not mean that your program was faulty. Though it may be elsewhere, I see nothing wrong with it.

[FortranFan]

@Jarzebski, Pawel,

As mentioned by Arjen Markus, an internal compiler error is a compiler bug and Intel wants you to submit support incidents which you can do at their Online Service Center (OSC):

https://supporttickets.intel.com/?lang=en-US

By the way, take a look again at your code: with i=1, when the inner loop begins, what do you expect as the beginning index value for the loop variable j?  It's undefined.

[mecej4]

As FortranFan pointed out, j is undefined at first use in your first version. Likewise, in your second version, start is undefined at first use. If the caller has not placed proper values in outmat%row and outmat%ptr,  you will again have errors.

[Jarzebski__Pawel]

Thanks Folks for your answers. I did not point out that clearly, but I posted it here more as a bugreport, rather than to ask what's wrong with my code. I'm aware that this code does nothing useful, I just wanted to show that it does compile without optimizations and does not with it.

Thank @FortranFan for the link, I did not post it there, since I wanted to have some public link to this case. I'll try now.

[Bernard]

Error code has a value of "Access Violation". It is quite interesting how usage of uninitalized variable 'j' caused this kind of ICE crash.

[mecej4]

iliyapolak wrote:
Error code has a value of "Access Violation". It is quite interesting how usage of uninitalized variable 'j' caused this kind of ICE crash. 

I did not draw that connection from the posts in this thread. We simply pointed out the presence of uninitialized variables as something to be concerned about.

The ICE occurred during compilation. Unless the compiler had been asked to generate code to do run-time checks, the presence of uninitialized variables in the code being compiled should have no effect on the compiler itself.

[Devorah_H_Intel]

Thank you for your report! This issue is better to be reported via our Online Service Center at https://supporttickets.intel.com/  
Instructions on how to file a ticket are available here: 
https://software.intel.com/en-us/articles/how-to-create-a-support-request-at-online-service-center  

[Bernard]

@mecej4

Yes I agree with you.