Procedure pointer component association problems

[jmcfarland101]

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

[Anonymous66]

Hello John,

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

Annalee

[jmcfarland101]

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

[jmcfarland101]

I will look into creating a minimal test case.

John

[jmcfarland101]

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

[Anonymous66]

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

[Udit_P_Intel]

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

[Ron_Green]

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

ron