- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote: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.
Perhaps you are confused by the "fun" in the name - here he means fun as in hilarity, not function.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> 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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page