Incorrect "name already used error" (again)

Incorrect "name already used error" (again)

Bild des Benutzers 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...

AnhangGröße
Herunterladen proc-pointer.f90729 Bytes
11 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers 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

Bild des Benutzers Steve Lionel (Intel)

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

Steve
Bild des Benutzers Steve Lionel (Intel)

I expect this to be fixed in Update 3.

Steve
Bild des Benutzers 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.

Bild des Benutzers 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...

Anlagen: 

AnhangGröße
Herunterladen proc-pointer2.f90619 Bytes
Bild des Benutzers Steve Lionel (Intel)

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.

Steve
Bild des Benutzers 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

www.quickthreadprogramming.com
Bild des Benutzers Steve Lionel (Intel)

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

Steve
Bild des Benutzers Steve Lionel (Intel)

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

    CALL subsub(f)
  CONTAINS
    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.

Steve
Bild des Benutzers Steve Lionel (Intel)

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.

Steve

Melden Sie sich an, um einen Kommentar zu hinterlassen.