[Bug libgomp/94635] New: [OpenMP][Offloading] mapping with alloc/delete followed by map(from/fromto fails

[Bug libgomp/94635] New: [OpenMP][Offloading] mapping with alloc/delete followed by map(from/fromto fails

[burnus at gcc dot gnu.org]

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

            Bug ID: 94635
           Summary: [OpenMP][Offloading] mapping with alloc/delete
                    followed by map(from/fromto  fails
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: openmp, wrong-code
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Based on an OpenMP test case from SOLLVE_VV,
   https://github.com/SOLLVE/sollve_vv/
Namely, based on
  tests/4.5/target_enter_exit_data/
    test_target_enter_exit_data_allocate_array_alloc_delete.F90

The following test case works if one comments:
  !$omp target enter data map(alloc: my1DPtr(:))
  !$omp target exit data map(delete: my1DPtr(:))
Then it prints the expected
  42 …
  10 …
  10 …
  20 …

If one comments only the "map(delete:…)", it prints
  42 …
  10 …
  0 …   (should be: 10)
  10 …  (should be: 20)

And with alloc/delete enabled, it prints:
  42 …
  10 …
  20 20 … 31911936 17 31907872 17 31907952 (should be: 10)
  10 …  (should be: 20)

In the 'target': when using "my1DArr = 99", the garbage values are replaced by
99, i.e.  20 20 … 99 99 …  (twelf times 20 followed by eight times 99).

The testsuite first tests whether alloc/delete works – which does; only
re-using the alloc/delete space fails.


Test case:
----------
  implicit none
  INTEGER, PARAMETER :: N = 20
  INTEGER, ALLOCATABLE, DIMENSION(:) :: my1DPtr
  INTEGER, DIMENSION(N) :: my1DArr

  allocate(my1DPtr(N))

  !$omp target enter data map(alloc: my1DPtr(:))
  !$omp target exit data map(delete: my1DPtr(:))

  my1DPtr(:) = 10
  my1DArr = 42
  print *, my1DArr  ! = 42, okay
  print *, my1DPtr  ! = 10, okay

  !$omp target map(from: my1DArr) map(tofrom: my1DPtr(:))
    my1DArr = my1DPtr
    my1DPtr(:) = 20
  !$omp end target

  print *, my1DArr ! should be: 10 (not 0 or 20+garbage)
  print *, my1DPtr ! should be: 20 (and not 10)
END

[Bug libgomp/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Just showing the dump – without further analysis:

#pragma omp target enter data
   map(alloc:MEM[(c_char *)_9] [len: _8])  // _9 = my1dptr.data, _8 = 20*4
   map(to:my1dptr [pointer set, len: 64])
   map(alloc:my1dptr.data [pointer assign, bias: 0])

#pragma omp target exit data
   map(delete:MEM[(c_char *)_14] [len: _13]) // 

#pragma omp target num_teams(1) thread_limit(0)
   map(from:my1darr [len: 80])
   map(tofrom:MEM[(c_char *)_21] [len: _20])  // _21 = my1dptr.data, _20 = 20*4
   map(to:my1dptr [pointer set, len: 64])
   map(alloc:my1dptr.data [pointer assign, bias: 0])
  [child fn: MAIN__._omp_fn.0 (.omp_data_arr.22, .omp_data_sizes.23,
                               .omp_data_kinds.24)]

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
          Component|libgomp                     |middle-end
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-04-17

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 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:af557050fd011a03d21dc26b31959033061a0443

commit r10-7777-gaf557050fd011a03d21dc26b31959033061a0443
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Apr 17 19:08:55 2020 +0200

    [OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

            PR middle-end/94635
            * gimplify.c (gimplify_scan_omp_clauses): Turn MAP_TO_PSET to
            MAP_DELETE.

            PR middle-end/94635
            * testsuite/libgomp.fortran/target-enter-data-2.F90: New.

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
FIXED on trunk/GCC 10.

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:3f5d94c192b81a3868f32f309dadd5571ef51cdf

commit r10-7833-g3f5d94c192b81a3868f32f309dadd5571ef51cdf
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Mon Apr 20 16:15:07 2020 +0200

    Add 'dg-do run' to 'libgomp.fortran/target-enter-data-2.F90'

    Fix-up for commit af557050fd011a03d21dc26b31959033061a0443 "[OpenMP] Fix
'omp
    exit data' for Fortran arrays (PR 94635)".

            libgomp/
            PR middle-end/94635
            * testsuite/libgomp.fortran/target-enter-data-2.F90: Add 'dg-do
            run'.

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

--- 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:9f0f7da9aa98eec28b4e5e34ade0aa0028df161d

commit r11-412-g9f0f7da9aa98eec28b4e5e34ade0aa0028df161d
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri May 15 11:50:34 2020 +0200

    [OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

    gcc/
            PR middle-end/94635
            * gimplify.c (gimplify_scan_omp_clauses): For MAP_TO_PSET with
            OMP_TARGET_EXIT_DATA, use 'release:' unless the associated
            item is 'delete:'.

    gcc/testsuite
            PR middle-end/94635
            * gfortran.dg/gomp/target-exit-data.f90: New.

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8156-ga7c5803d4e56c6f6c84a9c5b08adffb0cfe1d79f
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue May 19 10:10:21 2020 +0200

    [OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

            Backport from mainline
            2020-05-15  Tobias Burnus  <tobias@codesourcery.com>

    gcc/
            PR middle-end/94635
            * gimplify.c (gimplify_scan_omp_clauses): For MAP_TO_PSET with
            OMP_TARGET_EXIT_DATA, use 'release:' unless the associated
            item is 'delete:'.

    gcc/testsuite
            PR middle-end/94635
            * gfortran.dg/gomp/target-exit-data.f90: New.