Incorrect "name already used error" (again)

[jmcfarland101]

The attached source code demonstrates an incorrect compiler error with a procedure pointer, using Intel Composer 2013.  Strangely, the error goes away if I take out the (unrelated) derived type definition.  See also an older post: http://software.intel.com/en-us/forums/topic/292448. ; These procedure pointers must be really tricky...

[jmcfarland101]

Hi,

I'm just following up, it looks like this may have slipped through the cracks when it was posted.  I have provided a minimal test case for a compiler bug relating to procedure pointers.  I just wanted to make sure this has gotten into the system, or if I need to file somewhere else, please let me know.

John

[Steven_L_Intel1]

Sorry that this was overlooked before.  I have escalated this as issue DPD200240678.

[Steven_L_Intel1]

I expect this to be fixed in Update 3.

[jmcfarland101]

Thanks Steve.  I installed Update 3 and verified that it does resolve the issue with the test case that I posted.  However, when I try to compile the real project that this issue originated from, I get an internal compiler error associated with the same source file that originally had the issue.  The output I get from IVF is:

20000_0
: catastrophic error: **Internal compiler error: internal abort** 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.

I will poke around some more and see if I am able to reduce it to a simple test case.  I suspect the crash is still related to handling of procedure pointer derived type components, which we use extensively in this particular project.

[jmcfarland101]

Well, here's the trivial test case that triggers this ICE.  I feel like I should be named an honorary developer or get a free license or something...

[Steven_L_Intel1]

Thanks for the example - I will let the developers know. My guess is it's the use of the host-associated procedure pointer in a contained routine. Issue ID is DPD200242726.

[jimdempseyatthecove]

Steve,

In looking at the attached .f90 provided by jmcfarland101 the culprit may be related to a post on a different thread where the user had nested contains. I don't recall the link right now but to jog your memory, he used omp_get_thread_num() in and outer layer, saved the result in a user type then compared omp_get_thread_num() in an inner layer and got the wrong result. IOW the reference was pointing in the wrong position. In this case the reference is a function pointer. Executing f in this case uses a reference that is not to the correct location in the call stack. IOW fixing one, may fix the other.

Jim Dempsey

[Steven_L_Intel1]

Jim, this is an internal compiler error - it doesn't even get as far as executing. But yes, the nested contains is relevant.

[Steven_L_Intel1]

A workaround is to pass the pointer as an argument into the contained routine, for example:

[fortran]
    CALL subsub(f)
  CONTAINS
    SUBROUTINE subsub(f2)
    PROCEDURE(foo), pointer :: f2
      PRINT*, 'calling foo:', f2(1d0)
[/fortran]

I know this is somewhat ugly, but it will get you going again.

[Steven_L_Intel1]

It appears that the problem reported in #6 got fixed as part of the general work done on compiler version 14, as the bug is no longer reproducible in that version.