topic Thank you for the reproducer. in Intel® Fortran Compiler

Procedure pointer component association problems

jmcfarland101 — Thu, 25 Apr 2013 13:48:29 GMT

Hello Steve,

I went ahead and used the workaround you suggested at http://software.intel.com/en-us/forums/topic/339466, and I am now able to get this particular project to compile. However, I am getting some runtime behavior related to procedure pointer association that I believe is not correct. Basically I have a subroutine that accepts a derived type and a procedure pointer, and sets one of the derived type procedure pointer components to point to the dummy argument. The problem is, immediately after the line that does this, a different procedure pointer component, which was unassociated before, now becomes associated, even though it hasn't been touched. Here is some pseudo code that demonstrates this:

[fortran]
TYPE Object
PROCEDURE(), POINTER, NOPASS :: f => NULL()
PROCEDURE(), POINTER, NOPASS :: g => NULL()
END TYPE Object

SUBROUTINE foo(o, farg)
TYPE (Object) :: o
PROCEDURE(), POINTER :: farg
! At this point, o%g is not associated
o%f => farg
! Now o%g has become associated even though I didn't touch it
END SUBROUTINE foo
[/fortran]

Any thoughts on this, or does this sound like a compiler bug?

Thanks,
John

P.S. Can you confirm that the f and g components in my example are guaranteed to be not associated when a new instance of TYPE(Object) is declared? (I don't think this has to do with my problem, since I did confirm that o%g is not associated before the line of interest.)

Hello John,

Anonymous66 — Thu, 25 Apr 2013 19:18:29 GMT

Hello John,

What you are describing would be bug. Could you submit a running program which demonstrates this issue?

Annalee

Sorry, this got double posted

jmcfarland101 — Thu, 25 Apr 2013 19:36:12 GMT

Sorry, this got double posted. Please feel free to delete one of the duplicate threads. (It took a while for the original post to show up, so I thought it hadn't gone through).

I will look into creating a

jmcfarland101 — Thu, 25 Apr 2013 19:40:48 GMT

I will look into creating a minimal test case.

John

Attached is a reduced test

jmcfarland101 — Mon, 29 Apr 2013 21:19:30 GMT

Attached is a reduced test case. It should print False ,False; instead it prints False, True.

Some of the complexity (compared to my original pseudo-code example) was necessary to trigger the bug.

John

Thank you for the reproducer.

Anonymous66 — Mon, 29 Apr 2013 23:23:30 GMT

Thank you for the reproducer. I have escalated this issue to the developers, the issue number is DPD200243783. I will post any updates I receive to this thread.

Annalee

Interchanging the order of

Udit_P_Intel — Thu, 16 Jan 2014 19:48:25 GMT

Interchanging the order of field declarations inside TYPE COMPONENT, so that the procedure pointer is not the first field, causes the error to go away. Try:

TYPE Component
PROCEDURE(response_template), POINTER, NOPASS :: foo
TYPE (MulticallFunction) :: mc
END TYPE Component

instead of:

TYPE Component
TYPE (MulticallFunction) :: mc
PROCEDURE(response_template), POINTER, NOPASS :: foo
END TYPE Component

This bug was fixed in the

Ron_Green — Tue, 09 Sep 2014 20:11:17 GMT

This bug was fixed in the recently released v15.0 compiler, aka "Composer XE 2015"

ron