It seems that not a pointer is transferred but a value in the following case. Here is the tracking info: gfortran -g fptr_transfer.f90 -o fptr_transfer && ./fptr_transfer Segmentation fault (core dumped)gdb fptr_transfer core [...] Program terminated with signal 11, Segmentation fault. #0 0x0000000000400629 in assign_proc_ptr (ptr=0x0, obj1=( 0x40060c <proc> )) at fptr_transfer.f90:32 32 ptr => obj1%proc (gdb) where #0 0x0000000000400629 in assign_proc_ptr (ptr=0x0, obj1=( 0x40060c <proc> )) at fptr_transfer.f90:32 #1 0x0000000000400687 in transfer_proc_ptr (obj2=( 0 ), obj1=( 0x40060c <proc> )) at fptr_transfer.f90:26 #2 0x000000000040064c in foo () at fptr_transfer.f90:19 #3 0x00000000004006c2 in main (argc=1, argv=0x7ffff12d2fe4 './fptr_transfer\000') at fptr_transfer.f90:19 #4 0x00007f1d9cdf0586 in __libc_start_main () from /lib64/libc.so.6 #5 0x0000000000400549 in _start () at ../sysdeps/x86_64/elf/start.S:113 Current language: auto; currently fortran (gdb) Here is the corresponding code: subroutine proc () end subroutine proc program foo interface subroutine proc () end subroutine proc end interface type :: container_t procedure(proc), nopass, pointer :: proc => null () end type container_t type(container_t), target :: obj1 type(container_t) :: obj2 obj1%proc => proc call transfer_proc_ptr (obj2, obj1) contains subroutine transfer_proc_ptr (obj2, obj1) type(container_t), intent(out) :: obj2 type(container_t), intent(in), target :: obj1 call assign_proc_ptr (obj2%proc, obj1) end subroutine transfer_proc_ptr subroutine assign_proc_ptr (ptr, obj1) procedure(proc), pointer :: ptr type(container_t), intent(in), target :: obj1 ptr => obj1%proc end subroutine assign_proc_ptr end program foo
Created attachment 18335 [details] Example file which shows the PP problem
Confirmed. -fdump-tree-original shows: assign_proc_ptr (void (*<T63>) (void) * ptr, struct container_t & obj1) { *ptr = obj1->proc; }
Actually the part of the dump shown in comment #2 is ok. The problematic piece is this: transfer_proc_ptr (struct container_t & obj2, struct container_t & obj1) { [...] assign_proc_ptr (obj2->proc, (struct container_t *) obj1); } Here the obj2->proc is missing an "&".
This problems seems to be similar to PR 40450.
This patchlet should fix it: Index: gcc/fortran/trans-expr.c =================================================================== --- gcc/fortran/trans-expr.c (revision 150621) +++ gcc/fortran/trans-expr.c (working copy) @@ -2679,7 +2679,8 @@ gfc_conv_procedure_call (gfc_se * se, gf && fsym->attr.flavor != FL_PROCEDURE) || (fsym->attr.proc_pointer && !(e->expr_type == EXPR_VARIABLE - && e->symtree->n.sym->attr.dummy)))) + && e->symtree->n.sym->attr.dummy)) + || gfc_is_proc_ptr_comp (e, NULL))) { /* Scalar pointer dummy args require an extra level of indirection. The null pointer already contains
Subject: Bug 41022 Author: janus Date: Tue Aug 11 20:08:35 2009 New Revision: 150665 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150665 Log: 2009-08-11 Janus Weil <janus@gcc.gnu.org> PR fortran/41022 * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer components as actual arguments. 2009-08-11 Janus Weil <janus@gcc.gnu.org> PR fortran/41022 * gfortran.dg/proc_ptr_comp_14.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
Fixed with r150665. Thanks for the report.
The fix seems not to work with the test program. On Linux 32 bit I get the following when compiling: /tmp/cciQlmr1.o: In function `MAIN__': foo.f90:(.text+0x1b): undefined reference to `proc_' collect2: ld returned 1 exit status and on MAC OS X: Undefined symbols: "_proc_", referenced from: _proc_$non_lazy_ptr in ccJFt47G.o ld: symbol(s) not found collect2: ld returned 1 exit status
Sorry, false alarm. Had a truncated test file.