Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Associate construct referencing pointer function result

IanH
Honored Contributor II
309 Views

Dang, foiled again.

MODULE m
  IMPLICIT NONE
  
  TYPE :: t
    INTEGER, ALLOCATABLE :: comp
  END TYPE t
  
  TYPE(t), SAVE, TARGET :: array(10)
CONTAINS
  FUNCTION ptr_fun()
    TYPE(t), POINTER :: ptr_fun
    ptr_fun => array(1)
  END FUNCTION ptr_fun
END MODULE m

PROGRAM p
  USE m
  IMPLICIT NONE
  CALL run
CONTAINS
  SUBROUTINE run
    ASSOCIATE(p => ptr_fun())
    END ASSOCIATE
  END SUBROUTINE run
END PROGRAM p


 

>ifort /check:all /warn:all /standard-semantics "2016-07-19 assoc-ptr-fun.f90" && "2016-07-19 assoc-ptr-fun.exe"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.3.207 Build 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2016-07-19 assoc-ptr-fun.exe"
-subsystem:console
"2016-07-19 assoc-ptr-fun.obj"
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
2016-07-19 assoc-  00007FF690250C05  Unknown               Unknown  Unknown
2016-07-19 assoc-  00007FF690222114  Unknown               Unknown  Unknown
2016-07-19 assoc-  00007FF6902211C0  Unknown               Unknown  Unknown
2016-07-19 assoc-  00007FF6902210F1  Unknown               Unknown  Unknown
2016-07-19 assoc-  00007FF69024D5AE  Unknown               Unknown  Unknown
2016-07-19 assoc-  00007FF69024DE99  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFE283B8102  Unknown               Unknown  Unknown
ntdll.dll          00007FFE28C2C5B4  Unknown               Unknown  Unknown

I think the compiler might be trying to deallocate the allocatable component in the pointer result.

0 Kudos
7 Replies
jimdempseyatthecove
Honored Contributor III
309 Views

It is not entirely clear as to what you are trying to do. Using this thread's title it appears that you want to deal with function pointers. If this is true, then your TYPE t does not hold a functor (C-speak) to a function returning an integer. In Fortran, a C-like functor is known as a procedure pointer. Look in the IVF documentation under procedure pointers.

Jim Dempsey

0 Kudos
IanH
Honored Contributor II
309 Views

pointer (adjective) function result - a function result that is a pointer.

`ptr_fun` is a function with a data pointer result.  I want to associate a name with the target of that result.  In the scope of ptr_fun I could declare a data pointer `type(t), pointer :: p`, and then just use normal pointer association `p => ptr_fun()` instead of the associate construct, but that would not be fun.

(There are semantic differences between the pointer association approach and the use of an associate construct, and I prefer the semantics of the latter for my particular use case.)

0 Kudos
Steven_L_Intel1
Employee
309 Views

Ian's supposition is correct - the compiler is trying to deallocate the allocatable component, which it has no reason to do. I also see a call to "allocate" in the generated code but this gets skipped over. Escalated as issue DPD200412786.

Within the ASSOCIATE block, P is associated with the target of the pointer and has the TARGET attribute, so it is effectively array(1). Nothing wrong with this at all. No function pointers are involved.

0 Kudos
jimdempseyatthecove
Honored Contributor III
309 Views

What is not shown in the code is if IanH intends to

PROGRAM p
  USE m
  IMPLICIT NONE
  CALL run
CONTAINS
  SUBROUTINE run
    integer :: iResult
    ! other thread on forum had issue of name conflict with procedure name
    ! I change p to ppp (which may not be necessary)
    ASSOCIATE(ppp => ptr_fun())
      iResult = ppp ! is this the intention...
      ! or
      iResult = ppp()
    END ASSOCIATE
  END SUBROUTINE run
END PROGRAM p

I am not arguing with how the compiler will interpret the code, rather the choice of names verses title of thread.

IMHO ptr_t would have been a better choice than ptr_fun...
or fun_to_return_ptr_to_t

Seeing that IanH was so gracious to post ICE with most horrible source ever, I am sure he will understand...

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.”

Jim Dempsey

 

 

0 Kudos
Steven_L_Intel1
Employee
309 Views

ppp is NOT a function - it is associated with the target of the pointer ptr_fun returns, which is array(1). Perhaps you are confused by the "fun" in the name - here he means fun as in hilarity, not function. There are no function pointers in this program.

0 Kudos
IanH
Honored Contributor II
309 Views

Steve Lionel (Intel) wrote:

Perhaps you are confused by the "fun" in the name - here he means fun as in hilarity, not function.

Well, a bit of both.  ptr_fun - "pointer function" - function with a pointer result, or fun with pointers.  But not fun_ptr - function pointer - pointer that can be associated with a function, or a pointer that just likes to hit the town and have a good time.

But for more fun (not function), here's the original code snippet that the example in the original post came from.

    ASSOCIATE(proc => GetProcedure(exsn%specific_ref))
      IF (ALLOCATED(proc%characteristics)) THEN
      ...

where GetProcedure doesn't return a procedure, and proc is a data object.  I don't write obfuscators because they are useful, I write them to avoid embarrassment.

0 Kudos
jimdempseyatthecove
Honored Contributor III
309 Views

>> I don't write obfuscators because they are useful, I write them to avoid embarrassment.

Like tying your jacket around your waist after you've had an accident? ;)

Humor aside, IVF should not have ab-ended.

Hope to see you again at IDF.

Jim Dempsey

0 Kudos
Reply