Incorrect "name already used error" (again)

Incorrect "name already used error" (again)

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:  These procedure pointers must be really tricky...

Downloadapplication/octet-stream proc-pointer.f90729 bytes
11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


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.


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

Retired 12/31/2016

I expect this to be fixed in Update 3.

Retired 12/31/2016

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:

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

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


Downloadapplication/octet-stream proc-pointer2.f90619 bytes

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.

Retired 12/31/2016


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

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

Retired 12/31/2016

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

    CALL subsub(f)
    SUBROUTINE subsub(f2)
    PROCEDURE(foo), pointer :: f2
      PRINT*, 'calling foo:', f2(1d0)

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

Retired 12/31/2016

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.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today