Compiler bug: ASSOCIATE to POINTER

[Daniel_Dopico]

Despite of being incorrect, my compiler throws a "Fatal: There has been an internal compiler error (C0000005)." with this small code. Could someone double check this? 

PROGRAM MAIN
    IMPLICIT NONE
       
    TYPE STATES
        REAL(8),POINTER,DIMENSION(:)::q
    END TYPE STATES
    TYPE(states) jointcoord,jointcoordN
    TARGET jointcoord
    INTEGER ind(3), i
   
    ind=[1,2,3]
    i=0
    ASSOCIATE(vars=>jointcoord%q(ind))
        i=i+1
    END ASSOCIATE
END PROGRAM MAIN

[mecej4]

Which version, platform?

On Windows, with 19.1U1, I can avoid the ICE by commenting out the ASSOCIATE and END ASSOCIATE lines; the associated name is never referenced in the body of the construct.

[Arjen_Markus]

FYI: I tried it on Linux, version 18.0.3, and I get the same or very similar ICE.

[Steve_Lionel · Accepted solution]

Internal Compiler Error is always a compiler bug. Please report it through the Online Service Center.

Not that it matters to this test case, but keep in mind that in an ASSOCIATE block, the associate variable does not have the POINTER or ALLOCATABLE attribute even if the selector does. This is something people tend to forget.

[Daniel_Dopico]

mecej4 (Blackbelt) wrote:

Which version, platform?

On Windows, with 19.1U1, I can avoid the ICE by commenting out the ASSOCIATE and END ASSOCIATE lines; the associated name is never referenced in the body of the construct.

I tried with 2019 update 2 and 2020. Thank you mecej4, I know how to avoid the ICE, I only wanted confirmation. You should never have it, you should have a compiler error, not an internal error.

[Daniel_Dopico]

Steve Lionel (Ret.) (Blackbelt) wrote:

Internal Compiler Error is always a compiler bug. Please report it through the Online Service Center.

Not that it matters to this test case, but keep in mind that in an ASSOCIATE block, the associate variable does not have the POINTER or ALLOCATABLE attribute even if the selector does. This is something people tend to forget.

Thank you Steve, that's the point, I know that the code is wrong and I know how to fix it and even how to avoid the internal error and have the right compiler error, but that doesn't change the fact that this is a bug, I just wanted confirmation that others can reproduce it before sending the ticket.

[Steve_Lionel]

I don't see anything in the source that is incorrect. Obviously if this program was run, it would be wrong because jointcoord%q was never allocated, but that would not affect compile-time processing. Maybe I have overlooked something.

[Daniel_Dopico]

Steve Lionel (Ret.) (Blackbelt) wrote:

I don't see anything in the source that is incorrect. Obviously if this program was run, it would be wrong because jointcoord%q was never allocated, but that would not affect compile-time processing. Maybe I have overlooked something.

Well, maybe I am mistaken, but I think that the code is wrong because q is a pointer, and you are doing vars=>jointcoord%q(ind), instead of vars=>jointcoord%q. If vars were a pointer, this should be wrong because you are pointing to a part of a pointer (not to the pointer itself) and I think this is forbidden. I don't know if this same rule applies for the ASSOCIATE because, as you said, the POINTER behavior is lost.

[FortranFan]

For whatever it's worth, I'm unable to see anything in the code in the original post that is disallowed by the Fortran standard.

The standard does prohibit the associate-name 'vars' from appearing in a variable-definition context on account of the vector subscript in the selector  But the shown code doesn't do anything with 'vars' so that this constraint doesn't apply.

It appears the Intel Fortran compiler runs into an error with the use of the vector subscript in the selector.  If anyone from Intel team is reading this, hopefully they will be pick up an additional example with an ICE from this post to their compiler test case.  Or OP can attach this to the support request for the code in the original post.

   type :: t
      integer, allocatable :: n(:)
   end type
   type(t) :: foo
   associate ( x => foo%n( [1] ) )
      print *, x
   end associate
end

Compiling with Intel(R) Visual Fortran Compiler 19.1.1.216 [Intel(R) 64]...
p.f90
fortcom: Fatal: There has been an internal compiler error (C0000005).

   type :: t
      integer, pointer :: n(:)
   end type
   type(t) :: foo
   associate ( x => foo%n( [1] ) )
      print *, x
   end associate
end

Compiling with Intel(R) Visual Fortran Compiler 19.1.1.216 [Intel(R) 64]...
p.f90
fortcom: Fatal: There has been an internal compiler error (C0000005)

[Daniel_Dopico]

FortranFan wrote:

For whatever it's worth, I'm unable to see anything in the code in the original post that is disallowed by the Fortran standard.

The standard does prohibit the associate-name 'vars' from appearing in a variable-definition context on account of the vector subscript in the selector  But the shown code doesn't do anything with 'vars' so that this constraint doesn't apply.

It appears the Intel Fortran compiler runs into an error with the use of the vector subscript in the selector.  If anyone from Intel team is reading this, hopefully they will be pick up an additional example with an ICE from this post to their compiler test case.  Or OP can attach this to the support request for the code in the original post.

   type :: t
      integer, allocatable :: n(:)
   end type
   type(t) :: foo
   associate ( x => foo%n( [1] ) )
      print *, x
   end associate
end

Compiling with Intel(R) Visual Fortran Compiler 19.1.1.216 [Intel(R) 64]...
p.f90
fortcom: Fatal: There has been an internal compiler error (C0000005).

   type :: t
      integer, pointer :: n(:)
   end type
   type(t) :: foo
   associate ( x => foo%n( [1] ) )
      print *, x
   end associate
end

Compiling with Intel(R) Visual Fortran Compiler 19.1.1.216 [Intel(R) 64]...
p.f90
fortcom: Fatal: There has been an internal compiler error (C0000005)

Thank you Fan, I have just put the ticket some minutes before your answer. I will include this thread to the ticket. 

[JohnNichols]

 type :: t

2      integer, allocatable :: n(:)

3   end type

You have not allocated n and this does cause a problem when you try and use it -- hard experience I learnt recently - if you run it and look at the 4th line with the debugger the n will be crap. 

I ran into this type of problem with the recent COVID analysis -- it is not a compiler error I suggest it is poor programming,it took me a while to find as I had missed allocating an array as yours are shown -- 

[FortranFan]

Nichols, John wrote:

 type :: t

2      integer, allocatable :: n(:)

3   end type

You have not allocated n and this does cause a problem when you try and use it -- hard experience I learnt recently - if you run it and look at the 4th line with the debugger the n will be crap. 

I ran into this type of problem with the recent COVID analysis -- it is not a compiler error I suggest it is poor programming,it took me a while to find as I had missed allocating an array as yours are shown -- 

Readers, especially @John Nichols, can take a note of couple of important points:

• The two cases posted in Quote #9 should be seen as minimal working examples (MWEs) to illustrate a compiler issue and as such, no one should look to these snippets as being reflective of good coding practices.  One can view MWEs as having their own set of 'ethos' which are apart from those in actual working code,
• An 'internal compiler error' (ICE) or a fatal error are egregious instances of compiler issues that are apart from 'good' or bad code.  And in this instance, the presence or absence of the ALLOCATE instruction with the component of 'foo' has nothing to do with the ICE. 

[JohnNichols]

Dear FortranFan:

Thank you for your comment.  

 PROGRAM start
    IMPLICIT NONE
       
    TYPE STATES
      
 REAL(8),POINTER,DIMENSION(:)::q
    END TYPE STATES
    TYPE(states) jointcoord,jointcoordN
    TARGET jointcoord
    INTEGER ind(3), i
   
    allocate (jointcoord%q(3))
    ind=[1,2,3]
    i=0
    ASSOCIATE(vars=>jointcoord%q)
        i=i+1
    END ASSOCIATE
    
    i = i+ 1
        !write(*,*)vars
END PROGRAM start

works perfectly well as I would have expected and the vars comes out a real(8) array with 3 elements, why would you want  use an integer array to assign 1, 2, 3 to the first elements of an array -- 

PROGRAM start
    IMPLICIT NONE
       
    TYPE STATES
      
 REAL(8),POINTER,DIMENSION(:)::q
    END TYPE STATES
    TYPE(states) jointcoord,jointcoordN
    TARGET jointcoord
    INTEGER ind(3), i
   
    !allocate (jointcoord%q(3))
    ind=[1,2,3]
    i=0
  !  jointcoord%q([1,2,3]) = 0.0
    ASSOCIATE(vars=>jointcoord%q)
        i=i+1
    END ASSOCIATE
    
    i = i+ 1
        !write(*,*)vars
END PROGRAM start

yields

I can make it work without difficulty except with weird original code, which logically to me does not make sense -- 

It may make sense to some, and it may be legal, but it is poor practice 

[JohnNichols]

 PROGRAM start
    IMPLICIT NONE
       
      
     REAL(8) q(3)
    INTEGER ind(3), i
   
    !allocate (jointcoord%q(3))
    ind=[1,2,3]
    i=0
  !  jointcoord%q([1,2,3]) = 0.0
    q(ind) = 0.0
        write(*,*)q
END PROGRAM start

Works perfectly well as long as q is declared - otherwise it throws an error 

jointcoord%q(ind)

is trying to assign three elements to an unallocated array -- this is clearly an error in any logical view.  

It works every which way unless you tell the associate to create an array of 3 elements that does not exist. 

Say it out loud in English - please assign vars to an array that is part of state that has three elements -- but it does not exist. 

As long as you say vars point at the array without a size it is going to be ok-

[JohnNichols]

Of course if we need an error code to say this is not allowed - so be it, but that means that you just tell Intel 

[Daniel_Dopico]

Thank you John for the interesting discussion, it is good always to take advantage of any oportunity to share knowledge and opinions, but if we stick to my original post, I have to say that I am with FortranFan: to me your question "why would yo want use an integer array..." is irrelevant. The code itself is not important, I obtained this error in a huge program which makes sense and the process to arrive at this small test is not always easy but it is not important. The final code doesn't need to make sense, be correct, or even compile! You can get a code which does not compile, but if this code throws the ICE, then it will be useful for Intel, that's the important part here, we are trying to have a minimal code which launches the error, that's why we don't bother in allocating anything, because that part is not useful for Intel at all, it just makes the code more complex.

[jimdempseyatthecove]

Right on Dops,

Internal compiler errors are like: Walking on thin ICE

You will never know if or when you will fall through. It is best to fix the compiler error.

Jim Dempsey

[mecej4]

Furthermore, if one is reporting an ICE and trying to reduce the size of the reproducer, often extra care is necessary to preserve the ICE while shortening the reproducer.

Even after the ICE has been preserved, one cannot be certain that fixing the ICE associated with the reproducer will also fix the ICE associated with the original code that generated an ICE.

[Daniel_Dopico]

jimdempseyatthecove (Blackbelt) wrote:

Right on Dops,

Internal compiler errors are like: Walking on thin ICE

You will never know if or when you will fall through. It is best to fix the compiler error.

Jim Dempsey

Yes Jim, I totally agree. It is important to fix it because sometimes you do something wrong and you are totally blind because the compiler won't tell you anything useful, except that it can't handle your code.

[Daniel_Dopico]

mecej4 (Blackbelt) wrote:

Furthermore, if one is reporting an ICE and trying to reduce the size of the reproducer, often extra care is necessary to preserve the ICE while shortening the reproducer.

Even after the ICE has been preserved, one cannot be certain that fixing the ICE associated with the reproducer will also fix the ICE associated with the original code that generated an ICE.

Yes, I you are right, that happened to me with at least one bug, that needed some iterations to be totally fixed because it was more than one only bug. But you always expect that this doesn't happen again, haha.

[Steve_Lionel]

As a former support engineer, I want to ask that you please always include BOTH the original source(s) and the minimal reproducer. More than once I have seen that the minimal reproducer got fixed but the original case did not. Compilers are complex things. Providing both allows both quick analysis and verification that you will be able to build with the fix in place.