[Bug fortran/96668] New: [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[Bug fortran/96668] New: [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

            Bug ID: 96668
           Summary: [OpenMP] Re-mapping allocated but previously
                    unallocated allocatable does not work
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: openmp, wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The exact behaviour is not well specified in OpenMP 4.5 or 5.0 but at least
with 'always' the following is expected to map.
(See OpenMP Issue 2152 + upcoming OpenMP TR9 – which require the always
modifier. There is code which expects that implicit mapping and mapping without
always modifier also works.)

For pointers, at least OpenMP 5.0 seems to require that the POINTER target is
automatically mapped:

module m
implicit none
  integer, pointer :: p1 => null()
  integer, pointer :: p1 => null()
  integer, allocatable :: a1, a2(:)
  !$omp declare target(p1, p2, a1, a2)
end module m

use m
implicit none
  integer, pointer :: q1, q2(:)
  q1 => null()
  q2 => null()
  integer, allocatable :: b1, b2(:)
  allocate (a1, source=12)
  allocate (a2, source=[11,22,33])
  allocate (p1, source=42)
  allocate (p2, source=[1,3,5,7])

  !$omp target data map(b1, b2, q1, q2)
     allocate (b1, source=35)
     allocate (b2, source=[10,11,12,13,14])
     allocate (q1, source=4)
     allocate (q2, source=[9,8,7,6,5,4])

     ! allocatable, TR9 requires 'always' modifier:
     !$omp target map(always, tofrom: a1, a2, b1, b2)
       if (.not. allocated(a1)) stop 1
       if (.not. allocated(a2)) stop 1
       if (.not. allocated(b1)) stop 1
       if (.not. allocated(b2)) stop 1
       if (size(a2) /= 3) stop 1
       if (size(b2) /= 5) stop 1
       if (a1 /= 12) stop 1
       if (any (a2 /= [11,22,33])) stop 1
       if (b1 /= 42) stop 1
       if (any (b2 /= [10,11,12,13,14])) stop 1
       a1 = 3
       a2(:) = [44,55,66]
       b1 = 68
       b2(:) = [101, 102, 103, 104, 105]
     !$omp end target

     ! pointer: allegedly target is automatically mapped
     ! without requiring an explicit mapping or even the always modifier
     !$omp target  !! map(always, tofrom: p1, p2, q1, q2)
       if (.not. associated(p1)) stop 1
       if (.not. associated(p2)) stop 1
       if (.not. associated(q1)) stop 1
       if (.not. associated(q2)) stop 1
       if (size(p2) /= 4) stop 1
       if (size(q2) /= 6) stop 1
       if (p1 /= 42) stop 1
       if (any (p2 /= [1,3,5,7])) stop 1
       if (q1 /= 4) stop 1
       if (any (q2 /= [9,8,7,6,5,4])) stop 1
       p1 = 373
       p2(:) = [2,4,6,8]
       q1 = 497
       q2(:) = [-1, -2, -3, -4, -5, -6]
     !$omp end target
  !$omp end target data

  if (a1 /= 3) stop 1
  if (any (a2 /= [44,55,66])) stop 1
  if (b1 /= 68) stop 1
  if (any (b2 /= [10,11,12,13,14])) stop 1

  if (p1 /= 373) stop 1
  if (any (p2 /= [2,4,6,8])) stop 1
  if (q1 /= 397) stop 1
  if (any (q2 /= [-1, -2, -3, -4, -5, -6])) stop 1

  deallocate(a1, a2, b1, b2, p1, p2, q1, q2)
end

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cltang at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #0)
>      ! pointer: allegedly target is automatically mapped
>      ! without requiring an explicit mapping or even the always modifier
>      !$omp target  !! map(always, tofrom: p1, p2, q1, q2)

Namely:
"If a list item in a map clause is an associated pointer and
 the pointer is not the base pointer of another list item in
 a map clause on the same construct, then it is treated as if
 its pointer target is implicitly mapped in the same clause.
 For the purposes of the map clause, the mapped pointer
 target is treated as if its base pointer is the associated pointer."

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[cltang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #2 from Chung-Lin Tang <cltang at gcc dot gnu.org> ---
Note that what I'm working on at the moment does not include the Fortran parts,
and this particular feature appears to be more suitable to be implemented
within the Fortran FE, I think.

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> The exact behaviour is not well specified in OpenMP 4.5 or 5.0 but at least
> with 'always' the following is expected to map.
> (See OpenMP Issue 2152 + upcoming OpenMP TR9 – which require the always
> modifier. There is code which expects that implicit mapping and mapping
> without always modifier also works.)
> 
> For pointers, at least OpenMP 5.0 seems to require that the POINTER target
> is automatically mapped:
> 
> module m
> implicit none
>   integer, pointer :: p1 => null()
>   integer, pointer :: p1 => null()
>   integer, allocatable :: a1, a2(:)
>   !$omp declare target(p1, p2, a1, a2)
> end module m
> 

Module m looks wrong.  Should the 2nd p1 be p2?

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to kargl from comment #3)
> >   integer, pointer :: p1 => null()
> >   integer, pointer :: p1 => null()

> Module m looks wrong.  Should the 2nd p1 be p2?
It should be "p2(:)"

(Thanks. I wrote it in the browser without cross checking – and as I planed to
do it, the VMware had disk access issues. Thus, I just hit 'submit' while the
browser was still running. Hence, there might be additional issues. I also
planned to enumerate the 'stop 1'.)

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:972da557463ec946a31577294764a186b9821012

commit r11-3200-g972da557463ec946a31577294764a186b9821012
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Sep 15 09:24:47 2020 +0200

    OpenMP/Fortran: Fix (re)mapping of allocatable/pointer arrays [PR96668]

    gcc/cp/ChangeLog:

            PR fortran/96668
            * cp-gimplify.c (cxx_omp_finish_clause): Add bool openacc arg.
            * cp-tree.h (cxx_omp_finish_clause): Likewise
            * semantics.c (handle_omp_for_class_iterator): Update call.

    gcc/fortran/ChangeLog:

            PR fortran/96668
            * trans.h (gfc_omp_finish_clause): Add bool openacc arg.
            * trans-openmp.c (gfc_omp_finish_clause): Ditto. Use
            GOMP_MAP_ALWAYS_POINTER with PSET for pointers.
            (gfc_trans_omp_clauses): Like the latter and also if the always
            modifier is used.

    gcc/ChangeLog:

            PR fortran/96668
            * gimplify.c (gimplify_omp_for): Add 'bool openacc' argument;
            update omp_finish_clause calls.
            (gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses,
            gimplify_expr, gimplify_omp_loop): Update omp_finish_clause
            and/or gimplify_for calls.
            * langhooks-def.h (lhd_omp_finish_clause): Add bool openacc arg.
            * langhooks.c (lhd_omp_finish_clause): Likewise.
            * langhooks.h (lhd_omp_finish_clause): Likewise.
            * omp-low.c (scan_sharing_clauses): Keep GOMP_MAP_TO_PSET cause for
            'declare target' vars.

    include/ChangeLog:

            PR fortran/96668
            * gomp-constants.h (GOMP_MAP_ALWAYS_POINTER_P): Define.

    libgomp/ChangeLog:

            PR fortran/96668
            * libgomp.h (struct target_var_desc): Add has_null_ptr_assoc
member.
            * target.c (gomp_map_vars_existing): Add always_to_flag flag.
            (gomp_map_vars_existing): Update call to it.
            (gomp_map_fields_existing): Likewise
            (gomp_map_vars_internal): Update PSET handling such that if a
nullptr is
            now allocated or if GOMP_MAP_POINTER is used PSET is updated and
pointer
            remapped.
            (GOMP_target_enter_exit_data): Hanlde GOMP_MAP_ALWAYS_POINTER like
            GOMP_MAP_POINTER.
            * testsuite/libgomp.fortran/map-alloc-ptr-1.f90: New test.
            * testsuite/libgomp.fortran/map-alloc-ptr-2.f90: New test.

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Fixed for pointer/allocatable arrays.

Still to be done: scalar pointers/allocatable; here, one needs to be careful as
pointer/always pointer is already used for, e.g., struct mapping – and always
pointer currently assumes that the pointer is already present (assert;
change?).

Plus: ensure the refcounting works correctly.

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:1b9bdd52037061d7a5bd77d177b060c93c528a5d

commit r11-3211-g1b9bdd52037061d7a5bd77d177b060c93c528a5d
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Sep 15 21:28:40 2020 +0200

    libgomp/target.c: Silence -Wuninitialized warning

    libgomp/ChangeLog:

            PR fortran/96668
            * target.c (gomp_map_vars_internal): Initialize has_nullptr.

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #6)
> Fixed for pointer/allocatable arrays.
> 
> Still to be done: scalar pointers/allocatable; here, one needs to be careful
> as pointer/always pointer is already used for, e.g., struct mapping – and
> always pointer currently assumes that the pointer is already present
> (assert; change?).
> 
> Plus: ensure the refcounting works correctly.

Plus: Check that '!$omp update to(a)' for a previously unallocated var works
okay. (It probably does but needs to be checked.)

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:f6ce1e77bbf5d3a096f52e674bfd7354c6537d10

commit r13-3617-gf6ce1e77bbf5d3a096f52e674bfd7354c6537d10
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Fri Oct 28 15:06:45 2022 +0200

    Support OpenACC 'declare create' with Fortran allocatable arrays, part II
[PR106643, PR96668]

            PR libgomp/106643
            PR fortran/96668
            libgomp/
            * oacc-mem.c (goacc_enter_data_internal): Support
            OpenACC 'declare create' with Fortran allocatable arrays, part II.
            *
testsuite/libgomp.oacc-fortran/declare-allocatable-array_descriptor-1-directive.f90:
            Adjust.
            * testsuite/libgomp.oacc-fortran/pr106643-1.f90: New.