Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29285 Discussions

Procedure pointer component association problems

jmcfarland101
Beginner
1,034 Views

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

0 Kudos
7 Replies
Anonymous66
Valued Contributor I
1,034 Views

Hello John,

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

Annalee

0 Kudos
jmcfarland101
Beginner
1,034 Views

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

0 Kudos
jmcfarland101
Beginner
1,034 Views

I will look into creating a minimal test case.

John

0 Kudos
jmcfarland101
Beginner
1,034 Views

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

0 Kudos
Anonymous66
Valued Contributor I
1,034 Views

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

0 Kudos
Udit_P_Intel
Employee
1,034 Views


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

0 Kudos
Ron_Green
Moderator
1,034 Views

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

ron

0 Kudos
Reply