Bug 96080 - OpenACC/Fortran runtime library routines vs. Fortran 'pointer'
Summary: OpenACC/Fortran runtime library routines vs. Fortran 'pointer'
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 11.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: openacc
Depends on:
Blocks:
 
Reported: 2020-07-06 15:13 UTC by Thomas Schwinge
Modified: 2021-07-01 10:15 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-07-09 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Schwinge 2020-07-06 15:13:00 UTC
Do we have to clarify what 'acc_is_present' on a pointer means: whether the data it points to is present, or whether the pointer object itself is present -- or invalid?

    program main
      use openacc
      implicit none
      integer, dimension (:), allocatable, target :: a
      integer, dimension (:), pointer :: p
    
      allocate (a(10))
      !$acc enter data create(a)
      if (.not. acc_is_present (a)) stop 1
    
      p => a
      ! At this point, the data it points to is present, but the 'p' object itself isn't.
      if (acc_is_present (p)) stop 2
    
      !$acc enter data create(p)
      ! At this point, both the data it points to, and the 'p' object are present.
      if (.not. acc_is_present (p)) stop 3 !TODO This fails -- unexpectedly?
    
    end program main
Comment 1 Thomas Schwinge 2020-07-09 19:30:00 UTC
This problem does *not* seem to be specific to just 'acc_is_present', but probably all (?) OpenACC/Fortran runtime library routines?  Consider the following transcript, where we see the directives behave as expected for Fortran 'pointer' to 'dimension(:)', but the runtime library routines do not.

    program main
      use openacc
      implicit none
      integer, dimension(:), target :: data(19) ! 19 * 4 = 76 = 0x4c
      integer, dimension(:), pointer :: data_p
    
      call acc_create(data) ! h=0x7fffffffd6d0, s=76
      ! NEW
      ! (gdb) print tgt
      ! $2 = (struct target_mem_desc *) 0xa7b690
      ! (gdb) print/x *tgt
      ! $3 = {refcount = 0x1, array = 0xb19480, tgt_start = 0x7fffcf000000, tgt_end = 0x7fffcf00004c, to_free = 0x7fffcf000000, prev = 0x0, list_count = 0x1, device_descr = 0x80bae0, list = 0xa7b6d0}
      ! (gdb) print/x tgt->list[0]
      ! $4 = {key = 0xb19480, copy_from = 0x0, always_copy_from = 0x0, do_detach = 0x0, offset = 0x0, length = 0x4c}
    
      data_p => data
    
      call acc_copyin(data_p) ! h=0xb191b0, s=76
      ! NEW
      ! (gdb) print tgt
      ! $7 = (struct target_mem_desc *) 0xa7abc0
      ! (gdb) print/x *tgt
      ! $8 = {refcount = 0x1, array = 0xc21cd0, tgt_start = 0x7fffcf000200, tgt_end = 0x7fffcf00024c, to_free = 0x7fffcf000200, prev = 0x0, list_count = 0x1, device_descr = 0x80bae0, list = 0xa7ac00}
      ! (gdb) print/x tgt->list[0]
      ! $9 = {key = 0xc21cd0, copy_from = 0x0, always_copy_from = 0x0, do_detach = 0x0, offset = 0x0, length = 0x4c}
      ! That means, this creates a new mapping, 'acc_copyin(data_p)' does *not* dereference 'data_p => data'.  So far, so good?  But:
    
      print *, acc_is_present(data_p) ! h=0xb18db0, s=76
      ! Not mapped; this neither looks up the 'acc_create(data)', nor the 'acc_copyin(data_p)'.
    
      !$acc enter data copyin(data_p)
      ! 0 ("to" '*data_p.data')
      !   (gdb) print n
      !   $12 = (splay_tree_prefix_splay_tree_key) 0xb19480
      !     OLD 'data' -- expected
      !     '++dynamic_refcount'
      ! 1 ("pset" 'data_p'), 2 ("pointer assign" 'data_p.data')
      !   NEW
      !     Was somewhat expecting this would look up what 'acc_copyin(data_p)' mapped?
      !   (gdb) print tgt
      !   $4 = (struct target_mem_desc *) 0xc38000
      !   (gdb) print/x *tgt
      !   $5 = {refcount = 0x1, array = 0xc38770, tgt_start = 0x7fffcf000400, tgt_end = 0x7fffcf000440, to_free = 0x7fffcf000400, prev = 0x0, list_count = 0x2, device_descr = 0x80bae0, list = 0xc38040}
      !   (gdb) print/x tgt->list[0]
      !   $6 = {key = 0xc38770, copy_from = 0x0, always_copy_from = 0x0, do_detach = 0x0, offset = 0x0, length = 0x40}
      !   (gdb) print/x tgt->list[1] 
      !   $7 = {key = 0xc38770, copy_from = 0x0, always_copy_from = 0x0, do_detach = 0x0, offset = 0x0, length = 0x0}
    
      print *, acc_is_present(data_p) ! h=0xb18db0, s=76
      ! Same as above; still isn't mapped.
    
      !$acc serial present(data_p)
      ! 0 ("force_present" '*data_p.data')
      !   (gdb) print n
      !   $14 = (splay_tree_prefix_splay_tree_key) 0xb19480
      !     OLD 'data' -- expected
      ! 1 ("pset" 'data_p'), 2 ("pointer assign" 'data_p.data')
      !   (gdb) print n
      !   $10 = (splay_tree_prefix_splay_tree_key) 0xc38770
      !     OLD "pset" 'data_p' (from 'enter data copyin(data_p)') -- expected
      data_p(5) = 55
      !$acc end serial
    end program main
Comment 2 Thomas Schwinge 2020-07-09 20:00:16 UTC
In contrast, see the same example with 'dimension(:)' removed, that is, scalar data.  Here, we see the directives and the runtime library routines behave in the same way for Fortran 'pointer'.

    program main
      use openacc
      implicit none
      integer, target :: data
      integer, pointer :: data_p
    
      call acc_create(data) ! h=0x7fffffffd79c, s=4
      ! NEW
      ! (gdb) print tgt
      ! $2 = (struct target_mem_desc *) 0xa7a690
      ! (gdb) print/x *tgt
      ! $3 = {refcount = 0x1, array = 0xb18570, tgt_start = 0x7fffcf000000, tgt_end = 0x7fffcf000004, to_free = 0x7fffcf000000, prev = 0x0, list_count = 0x1, device_descr = 0x80aae0, list = 0xa7a6d0}
      ! (gdb) print/x tgt->list[0]
      ! $4 = {key = 0xb18570, copy_from = 0x0, always_copy_from = 0x0, do_detach = 0x0, offset = 0x0, length = 0x4}
    
      data_p => data
    
      call acc_copyin(data_p) ! h=0x7fffffffd79c, s=4
      ! This is 'data'!
      ! (gdb) print n
      ! $5 = (splay_tree_prefix_splay_tree_key) 0xb18570
      !   OLD 'data'
      !     '++dynamic_refcount'
      ! That means, this does *not* create a new mapping, 'acc_copyin(data_p)' *does* dereference 'data_p => data'.
      ! That means, we cannot use this to create a "pointer object 'data_p'" on the device.
    
      print *, acc_is_present(data_p) ! h=0x7fffffffd79c, s=4
      ! This is 'data'!
      ! (gdb) print n
      ! $6 = (splay_tree_prefix_splay_tree_key) 0xb18570
      ! Mapped.
    
      !$acc enter data copyin(data_p)
      ! 0 ("to" '*data_p'), 1 ("pointer assign" 'data_p')
      !   (gdb) print n
      !   $8 = (splay_tree_prefix_splay_tree_key) 0xb18570
      !     OLD 'data'
      !       '++dynamic_refcount'
    
      print *, acc_is_present(data_p) ! h=0x7fffffffd79c, s=4
      ! Same as above; mapped.
    
      !$acc serial present(data_p)
      ! 0 ("force_present" '*data_p')
      !   (gdb) print n
      !   $10 = (splay_tree_prefix_splay_tree_key) 0xb18570
      !     OLD 'data' -- expected
      ! 1 ("pointer assign" 'data_p')
      !   [...]
      data_p = 55
      !$acc end serial
    end program main

In contrast to an 'integer, dimension(:), pointer :: data_p', we cannot use an 'integer, pointer :: data_p' to create a "pointer object 'data_p'" on the device.  That's confusing (at least for me).  Plus the original confusion about 'acc_on_device' etc. behaving differently (non-sensical?).