[Bug middle-end/99928] New: [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[Bug middle-end/99928] New: [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[burnus at gcc dot gnu.org]

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

            Bug ID: 99928
           Summary: [OpenMP] reduction variable in combined target
                    construct wrongly mapped as firstprivate
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: openmp, wrong-code
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: anlauf at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Reported by Harald at
https://gcc.gnu.org/pipermail/fortran/2021-March/055896.html
with a Fortran program. But it also occurs for C as shown below.

OpenMP 5.1 has:
"If a list item appears in a reduction, lastprivate or linear clause
 on a combined target construct then it is treated as if it also appears
 in a map clause with a map-type of tofrom." (2.21.7)

Likewise OpenMP 5.0 in 2.19.7.

The FE chops the target-teams into target + teams and for target;
's' is implicitly mapped as 'firstprivate' instead of as 'map(tofrom:'.

It seems as if this is best done on the C/C++/Fortran FE which still sees that
it is a combined target construct.

int a[10];

int s2()
{
  int s = 0;
  #pragma omp target data map(a,s)
  {
    #pragma omp target teams reduction(+:s)
    {
      for (int i=0; i < 10; i++)
        s += a[i];
    }
  }
  return s;
}

Original dump:

 #pragma omp target data map(tofrom:s) map(tofrom:a)
  #pragma omp target
        #pragma omp teams reduction(+:s)

omplower dump:

        #pragma omp target data map(tofrom:s [len: 4]) map(tofrom:a [len: 40])
#pragma omp target num_teams(0) thread_limit(0) firstprivate(s) map(tofrom:a
[len: 40])
#pragma omp teams reduction(+:s) shared(a)

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes, that is new in OpenMP 5.0, 4.5 didn't have it.
Usually we do this in the gimplifier (gimplify_scan_omp_clauses), we also know
there whether it is a combined construct or not.
Look for the various spots where we omp_notice_variable in the outer context
there based on various conditions.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567838.html

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50768&action=edit
pr99928.tar.xz

I think we should start by checking what we are missing from the handling of
the harder clauses on combined/composite constructs against the 5.0 2.14
section.
By the harder clauses I mean firstprivate, lastprivate,
firstprivate+lastprivate, linear (explicit non-IV, explicit IV, implicit IV),
reduction and in_reduction.
I've tried to construct testcases attached here that hopefully handle all
possible cases and now the gimple dump should be checked against the rules.
The rules are known to be buggy in 5.0, but let's assume that reduction even
without inscan is tofrom on target combined with it as it was meant (and then
mistakenly broken, fixed in 5.1).
I've noticed we don't handle in_reduction clause on target construct.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> I think we should start by checking what we are missing from the handling of
> the harder clauses on combined/composite constructs against the 5.0 2.14
> section. [...]  in_reduction.

BTW: we already miss parser support for 'omp target in_reduction' - even
without combined constructs ...

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, I've noticed that when looking at combined constructs because otherwise
the  2.14 rule that in_reduction when on target shall be also
map(always,tofrom:) doesn't make any sense.

Anyway, we have some known differences in the handling of the oldest cases
(parallel for, parallel sections).
And we have the stuff I've put into the tarball already compile time covered in
c-c++-common/gomp/clauses-1.c hopefully, but I think it would be finally worth
it to add scan-tree-dump gimple checks on these simplified testcases (with 1 or
2 clauses instead of all possible ones), with xfails for the cases we don't
handle correctly and comments for those xfailed cases.
I'll work on that now.

And your patch is in the review queue, but I think it is better to figure out
what we do wrong and how much first.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu May 13 16:53:48 2021 +0200

    openmp: Add testcases to verify OpenMP 5.0 2.14 and OpenMP 5.1 2.17 rules
[PR99928]

    In preparation of PR99928 patch review, I've prepared testcases with
clauses
    that need more interesting handling on combined/composite constructs,
    in particular firstprivate, lastprivate, firstprivate+lastprivate, linear
    (explicit on non-iv, explicit on simd iv, implicit on simd iv, implicit on
    simd iv declared in the construct), reduction (scalars, array sections of
    array variables, array sections with pointer bases) and in_reduction.

    OpenMP 5.0 had the wording broken for reduction, the intended rule to use
    map(tofrom:) on target when combined with it was bound only on inscan
modifier
    presence which makes no sense, as then inscan may not be used, this has
    been fixed in 5.1 and I'm just assuming 5.1 wording for that.

    There are various cases where e.g. from historical or optimization reasons
    GCC slightly deviates from the rules, but in most cases it is something
    that shouldn't be really observable, e.g. whether
      #pragma omp parallel for firstprivate(x)
    is handled as
      #pragma omp parallel shared(x)
      #pragma omp for firstprivate(x)
    or
      #pragma omp parallel firstprivate(x)
      #pragma omp for
    shouldn't be possible to distinguish in user code.  I've added FIXMEs
    in the testcases about that, but maybe we just should keep it as is
    (alternative would be to do it in standard compliant way and transform
    into whatever we like after gimplification (e.g. early during omplower)).
    Some cases we for historical reasons implement even with clauses on
    constructs which in the standard don't accept them that way and then
    handling those magically in omp lowering/expansion, in particular e.g.
      #pragma omp parallel for firstprivate(x) lastprivate(x)
    we treat as
      #pragma omp parallel firstprivate(x) lastprivate(x)
      #pragma omp for
    even when lastprivate is not valid on parallel.  Maybe one day we
    could change that if we make sure we don't regress generated code quality.

    I've also found a bug in OpenMP 5.0/5.1,
      #pragma omp parallel sections firstprivate(x) lastprivate(x)
    incorrectly says that it should be handled as
      #pragma omp parallel firstprivate(x)
      #pragma omp sections lastprivate(x)
    which when written that way results in error; filed as
    https://github.com/OpenMP/spec/issues/2758
    to be fixed in OpenMP 5.2.  GCC handles it the way it used to do
    and users expect, so nothing to fix on the GCC side.

    Also, we don't support yet in_reduction clause on target construct,
    which means the -11.c testcase can't include any tests about in_reduction
    handling on all the composite constructs that include target.

    The work found two kinds of bugs on the GCC side, one is the known thing
    that we implement still the 4.5 behavior and don't mark for
    lastprivate/linear/reduction the list item as map(tofrom:) as mentioned
    in PR99928.  These cases are xfailed in the tests.

    And another one is with r21 and r28 in -{8,9,10}.c tests - we don't add
    reduction clause on teams for
      #pragma omp {target ,}teams distribute simd reduction(+:r)
    even when the spec says that teams shouldn't receive reduction only
    when combined with loop construct.

    In
    make check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
gomp.exp=pr99928*'
    testing this shows:

      # of expected passes          5648
      # of expected failures        872

    and with Tobias' patch applied:

      # of expected passes          5648
      # of unexpected successes     384
      # of expected failures        488

    2021-05-13  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
            * c-c++-common/gomp/pr99928-1.c: New test.
            * c-c++-common/gomp/pr99928-2.c: New test.
            * c-c++-common/gomp/pr99928-3.c: New test.
            * c-c++-common/gomp/pr99928-4.c: New test.
            * c-c++-common/gomp/pr99928-5.c: New test.
            * c-c++-common/gomp/pr99928-6.c: New test.
            * c-c++-common/gomp/pr99928-7.c: New test.
            * c-c++-common/gomp/pr99928-8.c: New test.
            * c-c++-common/gomp/pr99928-9.c: New test.
            * c-c++-common/gomp/pr99928-10.c: New test.
            * c-c++-common/gomp/pr99928-11.c: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 50810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50810&action=edit
Fortran version of the  C testcases (see comment 7 for notes)

Fortran conversion of the C/C++ testcases of comment 7 /
r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d

Currently fails to compile due to those issues:
* 'taskloop' not yet implemented
* 'loop' not yet implemented
* 'parallel master' not supported
* 'reduction(+:r00[1:2])' not supported (also not with '[...]' replaced by
'(...)')

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #7)
> Created attachment 50810 [details]
> Fortran version of the  C testcases (see comment 7 for notes)
> 
> Fortran conversion of the C/C++ testcases of comment 7 /
> r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d
> 
> Currently fails to compile due to those issues:
> * 'taskloop' not yet implemented
> * 'loop' not yet implemented
> * 'parallel master' not supported
> * 'reduction(+:r00[1:2])' not supported (also not with '[...]' replaced by
> '(...)')

I believe in Fortran those ought to be normal base language array sections,
so reduction(+:r00(2:3)) or so.
E.g. 5.0 says in [296:11] "The list items that appear in a reduction clause may
include array sections."
and [46:6-7] says: "Fortran has built-in support for array sections although
some restrictions apply to their use, as enumerated in the following section."
and later there are restrictions.
If we don't handle array sections in reduction, that would be missing item from
4.0 -> 4.5 support I think; do we handle array sections on map/to/from at
least?

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:780e5d4a2bac6eb7566c966a265961c99449cb55

commit r12-902-g780e5d4a2bac6eb7566c966a265961c99449cb55
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 19 09:21:09 2021 +0200

    openmp: Handle lastprivate on combined target correctly [PR99928]

    This patch deals with 2 issues:
    1) the gimplifier couldn't differentiate between
     #pragma omp parallel master
     #pragma omp taskloop simd
    and
     #pragma omp parallel master taskloop simd
    when there is a significant difference for clause handling between
    the two; as master construct doesn't have any clauses, we don't currently
    represent it during gimplification by an gimplification omp context at all,
    so this patch makes sure we don't set OMP_PARALLEL_COMBINED on parallel
master
    when not combined further.  If we ever add a separate master context during
    gimplification, we'd use ORT_COMBINED_MASTER vs. ORT_MASTER (or MASKED
probably).
    2) lastprivate when combined with target should be map(tofrom:) on the
target,
    this change handles it only when not combined with firstprivate though,
that
    will need further work (similarly to linear or reduction).

    2021-05-19  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
    gcc/
            * tree.h (OMP_MASTER_COMBINED): Define.
            * gimplify.c (gimplify_scan_omp_clauses): Rewrite lastprivate
            handling for outer combined/composite constructs to a loop.
            Handle lastprivate on combined target.
            (gimplify_expr): Formatting fix.
    gcc/c/
            * c-parser.c (c_parser_omp_master): Set OMP_MASTER_COMBINED on
            master when combined with taskloop.
            (c_parser_omp_parallel): Don't set OMP_PARALLEL_COMBINED on
            parallel master when not combined with taskloop.
    gcc/cp/
            * parser.c (cp_parser_omp_master): Set OMP_MASTER_COMBINED on
            master when combined with taskloop.
            (cp_parser_omp_parallel): Don't set OMP_PARALLEL_COMBINED on
            parallel master when not combined with taskloop.
    gcc/testsuite/
            * c-c++-common/gomp/pr99928-2.c: Remove all xfails.
            * c-c++-common/gomp/pr99928-12.c: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:94fa4c67b95c12482b6087d8eef2d72f7b7ea254

commit r12-936-g94fa4c67b95c12482b6087d8eef2d72f7b7ea254
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu May 20 09:17:40 2021 +0200

    openmp: Handle explicit linear clause properly in combined constructs with
target [PR99928]

    linear clause should have the effect of firstprivate+lastprivate (or for
IVs
    not declared in the construct lastprivate) on outer constructs and
eventually
    map(tofrom:) on target when combined with it.

    2021-05-20  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
            * gimplify.c (gimplify_scan_omp_clauses) <case OMP_CLAUSE_LINEAR>:
For
            explicit linear clause when combined with target, make it
map(tofrom:)
            instead of no clause or firstprivate.

            * c-c++-common/gomp/pr99928-4.c: Remove all xfails.
            * c-c++-common/gomp/pr99928-5.c: Likewise.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0c6e792dd5c96a48c873b73c2d5b1ee4fc4b6b8e

commit r12-990-g0c6e792dd5c96a48c873b73c2d5b1ee4fc4b6b8e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri May 21 21:13:06 2021 +0200

    openmp: Fix up handling of implicit lastprivate on outer constructs for
implicit linear and lastprivate IVs [PR99928]

    This patch fixes the handling of lastprivate propagation to outer
combined/composite
    leaf constructs from implicit linear or lastprivate clauses on simd IVs and
adds missing
    testsuite coverage for explicit and implicit lastprivate on simd IVs.

    2021-05-21  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
            * gimplify.c (omp_lastprivate_for_combined_outer_constructs): New
            function.
            (gimplify_scan_omp_clauses) <case OMP_CLAUSE_LASTPRIVATE>: Use it.
            (gimplify_omp_for): Likewise.

            * c-c++-common/gomp/pr99928-6.c: Remove all xfails.
            * c-c++-common/gomp/pr99928-13.c: New test.
            * c-c++-common/gomp/pr99928-14.c: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r12-991-gb5c1c7a96bc8d7062d2c35675f48131667498182
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri May 21 21:16:21 2021 +0200

    openmp: Fix up firstprivate+lastprivate clause handling [PR99928]

    The C/C++ clause splitting happens very early during construct parsing,
    but only the FEs later on handle possible instantiations, non-static
    member handling and array section lowering.
    In the OpenMP 5.0/5.1 rules, whether firstprivate is added to combined
    target depends on whether it isn't also mentioned in lastprivate or map
    clauses, but unfortunately I think such checks are much better done only
    when the FEs perform all the above mentioned changes.
    So, this patch arranges for the firstprivate clause to be copied or moved
    to combined target construct (as before), but sets flags on that clause,
    which tell the FE *finish_omp_clauses and the gimplifier it has been added
    only conditionally and let the FEs and gimplifier DTRT for these.

    2021-05-21  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
    gcc/
            * tree.h (OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET): Define.
            * gimplify.c (enum gimplify_omp_var_data): Fix up
            GOVD_MAP_HAS_ATTACHMENTS value, add GOVD_FIRSTPRIVATE_IMPLICIT.
            (omp_lastprivate_for_combined_outer_constructs): If combined target
            has GOVD_FIRSTPRIVATE_IMPLICIT set for the decl, change it to
            GOVD_MAP | GOVD_SEEN.
            (gimplify_scan_omp_clauses): Set GOVD_FIRSTPRIVATE_IMPLICIT for
            firstprivate clauses with OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT.
            (gimplify_adjust_omp_clauses): For firstprivate clauses with
            OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT either clear that bit and
            OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET too, or remove it and
            let it be replaced by implicit map clause.
    gcc/c-family/
            * c-omp.c (c_omp_split_clauses): Set
OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT
            on firstprivate clause copy going to target construct, and for
            target simd set also OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET bit.
    gcc/c/
            * c-typeck.c (c_finish_omp_clauses): Move firstprivate clauses with
            OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT to the end of the chain.  Don't
error
            if a decl is mentioned both in map clause and in such firstprivate
            clause unless OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET is also set.
    gcc/cp/
            * semantics.c (finish_omp_clauses): Move firstprivate clauses with
            OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT to the end of the chain.  Don't
error
            if a decl is mentioned both in map clause and in such firstprivate
            clause unless OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT_TARGET is also set.
    gcc/testsuite/
            * c-c++-common/gomp/pr99928-3.c: Remove all xfails.
            * c-c++-common/gomp/pr99928-15.c: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3a81735c1c8cea4323dcb912b7a8879b54aa3bc0

commit r12-1031-g3a81735c1c8cea4323dcb912b7a8879b54aa3bc0
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 25 11:07:01 2021 +0200

    openmp: Fix reduction clause handling on teams distribute simd [PR99928]

    When a directive isn't combined with worksharing-loop, it takes much
    simpler clause splitting path for reduction, and that one was missing
    handling of teams when combined with simd.

    2021-05-25  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
    gcc/c-family/
            * c-omp.c (c_omp_split_clauses): Copy reduction to teams when teams
is
            combined with simd and not with taskloop or for.
    gcc/testsuite/
            * c-c++-common/gomp/pr99928-8.c: Remove xfails from omp teams r21
and
            r28 checks.
            * c-c++-common/gomp/pr99928-9.c: Likewise.
            * c-c++-common/gomp/pr99928-10.c: Likewise.
    libgomp/
            * testsuite/libgomp.c-c++-common/reduction-17.c: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r12-1109-gc94424b0ed786ec92b6904da69af8b5243b34fdc
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri May 28 11:26:48 2021 +0200

    openmp: Fix up handling of reduction clause on constructs combined with
target [PR99928]

    The reduction clause should be copied as map (tofrom: ) to combined target
if
    present, but as we need different handling of array sections between map
and reduction,
    doing that during gimplification would be harder.

    So, this patch adds them during splitting, and similarly to firstprivate
adds them
    with a new flag that they should be just ignored/removed if an explicit map
clause
    of the same list item is present.

    The exact rules are to be decided in
https://github.com/OpenMP/spec/issues/2766
    so this patch just implements something that is IMHO reasonable and exact
detailed
    testcases for the cornercases will follow once it is clarified.

    2021-05-28  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
    gcc/
            * tree.h (OMP_CLAUSE_MAP_IMPLICIT): Define.
    gcc/c-family/
            * c-omp.c (c_omp_split_clauses): For reduction clause if combined
with
            target add a map tofrom clause with OMP_CLAUSE_MAP_IMPLICIT.
    gcc/c/
            * c-typeck.c (handle_omp_array_sections): Copy
OMP_CLAUSE_MAP_IMPLICIT.
            (c_finish_omp_clauses): Move not just
OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT
            marked clauses last, but also OMP_CLAUSE_MAP_IMPLICIT.  Add
            map_firstprivate_head bitmap, set it for
GOMP_MAP_FIRSTPRIVATE_POINTER
            maps and silently remove OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT if it is
            present too.  For OMP_CLAUSE_MAP_IMPLICIT silently remove the
clause
            if present in map_head, map_field_head or map_firstprivate_head
            bitmaps.
    gcc/cp/
            * semantics.c (handle_omp_array_sections): Copy
            OMP_CLAUSE_MAP_IMPLICIT.
            (finish_omp_clauses): Move not just
OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT
            marked clauses last, but also OMP_CLAUSE_MAP_IMPLICIT.  Add
            map_firstprivate_head bitmap, set it for
GOMP_MAP_FIRSTPRIVATE_POINTER
            maps and silently remove OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT if it is
            present too.  For OMP_CLAUSE_MAP_IMPLICIT silently remove the
clause
            if present in map_head, map_field_head or map_firstprivate_head
            bitmaps.
    gcc/testsuite/
            * c-c++-common/gomp/pr99928-8.c: Remove all xfails.
            * c-c++-common/gomp/pr99928-9.c: Likewise.
            * c-c++-common/gomp/pr99928-10.c: Likewise.
            * c-c++-common/gomp/pr99928-16.c: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5d21c0cbda0c4b109366f51534f328145da4c21f

commit r12-1119-g5d21c0cbda0c4b109366f51534f328145da4c21f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat May 29 10:05:38 2021 +0200

    openmp: Add shared to parallel for linear on parallel master taskloop simd
[PR99928]

    I forgot to add default(none) and defaultmap(none) wherever possible on the
    testcases to make sure none of the required clauses are added implicitly
(because
    in that case it doesn't work with these none arguments of those default*
clauses
    or works differently with other default* settings.

    And that revealed we didn't add shared on parallel for linear clause
    on parallel master taskloop simd, so this patch fixes that too.

    2021-05-29  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99928
            * gimplify.c (gimplify_scan_omp_clauses): For taskloop simd
            combined with parallel, make sure to add shared clause to
            parallel for explicit linear clause.

            * c-c++-common/gomp/pr99928-1.c: Add default(none) to constructs
            combined with parallel, teams or taskloop and defaultmap(none)
            to constructs combined with target.
            * c-c++-common/gomp/pr99928-2.c: Likewise.
            * c-c++-common/gomp/pr99928-3.c: Likewise.
            * c-c++-common/gomp/pr99928-4.c: Likewise.
            * c-c++-common/gomp/pr99928-5.c: Likewise.
            * c-c++-common/gomp/pr99928-6.c: Likewise.
            * c-c++-common/gomp/pr99928-7.c: Likewise.
            * c-c++-common/gomp/pr99928-8.c: Likewise.
            * c-c++-common/gomp/pr99928-9.c: Likewise.
            * c-c++-common/gomp/pr99928-10.c: Likewise.
            * c-c++-common/gomp/pr99928-13.c: Likewise.
            * c-c++-common/gomp/pr99928-14.c: Likewise.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 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:f6bf436d9ab907d090823895abb7a2d5ba7ff50c

commit r12-1139-gf6bf436d9ab907d090823895abb7a2d5ba7ff50c
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Jun 1 12:46:37 2021 +0200

    Fortran/OpenMP: Support (parallel) master taskloop (simd) [PR99928]

            PR middle-end/99928

    gcc/fortran/ChangeLog:

            * dump-parse-tree.c (show_omp_node, show_code_node): Handle
            (parallel) master taskloop (simd).
            * frontend-passes.c (gfc_code_walker): Set in_omp_workshare
            to false for parallel master taskloop (simd).
            * gfortran.h (enum gfc_statement):
            Add ST_OMP_(END_)(PARALLEL_)MASTER_TASKLOOP(_SIMD).
            (enum gfc_exec_op): EXEC_OMP_(PARALLEL_)MASTER_TASKLOOP(_SIMD).
            * match.h (gfc_match_omp_master_taskloop,
            gfc_match_omp_master_taskloop_simd,
            gfc_match_omp_parallel_master_taskloop,
            gfc_match_omp_parallel_master_taskloop_simd): New prototype.
            * openmp.c (gfc_match_omp_parallel_master_taskloop,
            gfc_match_omp_parallel_master_taskloop_simd,
            gfc_match_omp_master_taskloop,
            gfc_match_omp_master_taskloop_simd): New.
            (gfc_match_omp_taskloop_simd): Permit 'reduction' clause.
            (resolve_omp_clauses): Handle new combined directives; remove
            inscan-reduction check to reduce multiple errors; add
            task-reduction error for 'taskloop simd'.
            (gfc_resolve_omp_parallel_blocks,
            resolve_omp_do, omp_code_to_statement,
            gfc_resolve_omp_directive): Handle new combined constructs.
            * parse.c (decode_omp_directive, next_statement,
            gfc_ascii_statement, parse_omp_do, parse_omp_structured_block,
            parse_executable): Likewise.
            * resolve.c (gfc_resolve_blocks, gfc_resolve_code): Likewise.
            * st.c (gfc_free_statement): Likewise.
            * trans.c (trans_code): Likewise.
            * trans-openmp.c (gfc_split_omp_clauses,
            gfc_trans_omp_directive): Likewise.
            (gfc_trans_omp_parallel_master): Move after
gfc_trans_omp_master_taskloop;
            handle parallel master taskloop (simd) as well.
            (gfc_trans_omp_taskloop): Take gfc_exec_op as arg.
            (gfc_trans_omp_master_taskloop): New.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/gomp/reduction5.f90: Remove dg-error; the issue is
            now diagnosed with less error output.
            * gfortran.dg/gomp/scan-1.f90: Likewise.
            * gfortran.dg/gomp/pr99928-3.f90: New test.
            * gfortran.dg/gomp/taskloop-1.f90: New test.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 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:9ca24bd34b6ac44c17f949d89ff60d0fd4665133

commit r12-1158-g9ca24bd34b6ac44c17f949d89ff60d0fd4665133
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Wed Jun 2 11:48:21 2021 +0200

    Fortran/OpenMP: Add gfortran.dg/gomp/taskloop-2.f90 [PR99928]

            PR middle-end/99928

    gcc/testsuite/ChangeLog

            * gfortran.dg/gomp/taskloop-2.f90: New.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 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:178191e1dfafd8db149edcdef7a39e9e2c00f216

commit r12-1206-g178191e1dfafd8db149edcdef7a39e9e2c00f216
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Jun 4 12:06:59 2021 +0200

    Fortran/OpenMP: Add omp loop [PR99928]

            PR middle-end/99928

    gcc/fortran/ChangeLog:

            * dump-parse-tree.c (show_omp_clauses): Handle bind clause.
            (show_omp_node): Handle loop directive.
            * frontend-passes.c (gfc_code_walker): Likewise.
            * gfortran.h (enum gfc_statement): Add
            ST_OMP_(END_)(TARGET_)(|PARALLEL_|TEAMS_)LOOP.
            (enum gfc_omp_bind_type): New.
            (gfc_omp_clauses): Use it.
            (enum gfc_exec_op): Add EXEC_OMP_(TARGET_)(|PARALLEL_|TEAMS_)LOOP.
            * match.h (gfc_match_omp_loop, gfc_match_omp_parallel_loop,
            gfc_match_omp_target_parallel_loop,
gfc_match_omp_target_teams_loop,
            gfc_match_omp_teams_loop): New.
            * openmp.c (enum omp_mask1): Add OMP_CLAUSE_BIND.
            (gfc_match_omp_clauses): Handle it.
            (OMP_LOOP_CLAUSES, gfc_match_omp_loop, gfc_match_omp_teams_loop,
            gfc_match_omp_target_teams_loop, gfc_match_omp_parallel_loop,
            gfc_match_omp_target_parallel_loop): New.
            (resolve_omp_clauses, resolve_omp_do, omp_code_to_statement,
            gfc_resolve_omp_directive): Handle omp loop.
            * parse.c (decode_omp_directive case_exec_markers,
gfc_ascii_statement,
            parse_omp_do, parse_executable): Likewise.
            (parse_omp_structured_block): Remove ST_ which use parse_omp_do.
            * resolve.c (gfc_resolve_blocks): Add omp loop.
            * st.c (gfc_free_statement): Likewise.
            * trans-openmp.c (gfc_trans_omp_clauses): Handle bind clause.
            (gfc_trans_omp_do, gfc_trans_omp_parallel_do,
gfc_trans_omp_distribute,
            gfc_trans_omp_teams, gfc_trans_omp_target,
gfc_trans_omp_directive):
            Handle loop directive.
            (gfc_split_omp_clauses): Likewise; fix firstprivate/lastprivate
            and (in_)reduction for taskloop.
            * trans.c (trans_code): Handle omp loop directive.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/gomp/pr99928-3.f90: Add 'default(none)', following
            C/C++ version of the patch.
            * gfortran.dg/gomp/loop-1.f90: New test.
            * gfortran.dg/gomp/loop-2.f90: New test.
            * gfortran.dg/gomp/pr99928-1.f90: New test; based on C/C++ test.
            * gfortran.dg/gomp/pr99928-11.f90: Likewise.
            * gfortran.dg/gomp/pr99928-2.f90: Likewise.
            * gfortran.dg/gomp/pr99928-4.f90: Likewise.
            * gfortran.dg/gomp/pr99928-5.f90: Likewise.
            * gfortran.dg/gomp/pr99928-6.f90: Likewise.
            * gfortran.dg/gomp/pr99928-8.f90: Likewise.
            * gfortran.dg/goacc/omp.f95: Use 'acc kernels loops' instead
            of 'acc loops' to hide unrelated bug for now.
            * gfortran.dg/goacc/omp-fixed.f: Likewise

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 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:848a36032c8876ee45d5c81efeddb1bc657ac95c

commit r12-1207-g848a36032c8876ee45d5c81efeddb1bc657ac95c
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Jun 4 12:14:14 2021 +0200

    Fortran/OpenMP: omp loop's BIND clause - fix typo

    Missed a 'git add' after fixing this typo pointed out during review.

            PR middle-end/99928

    gcc/fortran/ChangeLog:

            * openmp.c (gfc_match_omp_clauses): Fix typo in error message.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/gomp/loop-2.f90: Update for typo fix.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[burnus at gcc dot gnu.org]

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

--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:
> commit r12-1207-g848a36032c8876ee45d5c81efeddb1bc657ac95c
>     Fortran/OpenMP: omp loop's BIND clause - fix typo
... and additionally:
commit r12-1211-gad3f0ad4bafe377072a53ded468fd9948e659f46
   gfortran.dg/gomp/pr99928-5.f90: Use proper iteration var

Missing / TODO on the *Fortran* side:

* gcc/testsuite/gfortran.dg/gomp/pr99928-9.f90
  gcc/testsuite/gfortran.dg/gomp/pr99928-10.f90
  i.e. Fortran version of those C/C++ test case
  (→ attachment 50810)
* reduction(+: arr(1:2))  ! Array slice support
* defaultmap(none) ! → PR90742
* xfails:
  - $omp parallel master taskloop (simd)
    parallel misses shared(...)
    for firstprivate/lastprivate/reduction variable 
  - 'omp target ... ' misses map(tofrom:)
    for firstprivate/lastprivate/reduction variable

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 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:245517470d6948a40cead9f5c312b8d79ac5c491

commit r12-1278-g245517470d6948a40cead9f5c312b8d79ac5c491
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Jun 8 09:51:09 2021 +0200

    Fortran/OpenMP: Fix clause splitting for target/parallel/teams [PR99928]

            PR middle-end/99928

    gcc/fortran/ChangeLog:

            * trans-openmp.c (gfc_add_clause_implicitly): New.
            (gfc_split_omp_clauses): Use it.
            (gfc_free_split_omp_clauses): New.
            (gfc_trans_omp_do_simd, gfc_trans_omp_parallel_do,
            gfc_trans_omp_parallel_do_simd, gfc_trans_omp_distribute,
            gfc_trans_omp_teams, gfc_trans_omp_target, gfc_trans_omp_taskloop,
            gfc_trans_omp_master_taskloop, gfc_trans_omp_parallel_master): Use
it.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/gomp/openmp-simd-6.f90: Update scan-tree-dump.
            * gfortran.dg/gomp/scan-5.f90: Likewise.
            * gfortran.dg/gomp/loop-1.f90: Likewise; remove xfail.
            * gfortran.dg/gomp/pr99928-1.f90: Remove xfail.
            * gfortran.dg/gomp/pr99928-2.f90: Likewise.
            * gfortran.dg/gomp/pr99928-3.f90: Likewise.
            * gfortran.dg/gomp/pr99928-8.f90: Likewise.

[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-03
     Ever confirmed|0                           |1
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=109701
             Status|UNCONFIRMED                 |NEW

--- Comment #22 from anlauf at gcc dot gnu.org ---
See also pr109701 which is a likely related.