[Bug c/100902] New: pointer attachment issues

[Bug c/100902] New: pointer attachment issues

[jakub at gcc dot gnu.org]

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

            Bug ID: 100902
           Summary: pointer attachment issues
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

On:

void
foo (int *ptr)
{
  #pragma omp target map (ptr, ptr[:4])
  #pragma omp parallel master
  ptr[0] = 1;
}

void
bar (int *ptr)
{
  #pragma omp target parallel map (ptr[:4], ptr)
  #pragma omp master
  ptr[0] = 1;
}

foo is compiled fine, but bar ICEs because c_omp_adjust_map_clauses isn't
called
on the combined constructs.

Another bug is that
void
baz (int *ptr)
{
  #pragma omp target map (ptr[:4], ptr)
  #pragma omp parallel master
  ptr[0] = 1;
}

void
qux (int *ptr)
{
  #pragma omp target parallel map (ptr, ptr[:4])
  #pragma omp master
  ptr[0] = 1;
}

is rejected by both C and C++ pointers twice with
‘ptr’ appears both in data and map clauses
The user ordering of clauses (which is reversed for the non-combined cases in
the implementation) should not matter.

I'll deal with the bar issue for now.

[Bug c/100902] pointer attachment issues

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As mentioned on gcc-patches, it is also unclear if it will DTRT for dependent
map clauses in templates.

[Bug c/100902] pointer attachment issues

[cvs-commit at gcc dot gnu.org]

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

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

commit r12-1246-g7fa4db39b6bcd207bd2bffff52023ff6b155bd15
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun Jun 6 19:37:06 2021 +0200

    openmp: Call c_omp_adjust_map_clauses even for combined target [PR100902]

    When looking at in_reduction support for target, I've noticed that
    c_omp_adjust_map_clauses is not called for the combined target case.

    The following patch fixes it.

    Unfortunately, there are other issues.

    One is (also mentioned in the PR) that currently the pointer attachment
    stuff seems to be clause ordering dependent (the standard says that clause
    ordering on the same construct does not matter), the baz and qux cases
    in the PR are rejected while when swapped it is accepted.
    Note, the order of clauses in GCC really is treated as insignificant
    initially and only later on the compiler can adjust the ordering (e.g. when
    we sort map clauses based on what they refer to etc.) and in particular,
    clauses from parsing is reverse of the order in user code, while
    c_omp_split_clauses performed for combined/composite constructs typically
    reverses that ordering, i.e. makes it follow the user code ordering.

    And another one is I'm slightly afraid c_omp_adjust_map_clauses might
    misbehave in templates, though haven't tried to verify it with testcases.
    When processing_template_decl, the non-dependent clauses will be handled
    usually the same as when not in a template, but dependent clauses aren't
    processed or only limited processing is done there, and rest is deferred
    till later.  From quick skimming of c_omp_adjust_map_clauses, it seems
    it might not be very happy about non-processed map clauses that might
    still have the TREE_LIST representation of array sections, or might
    not have finalized decls or base decls etc.
    So, for this I wonder if cp_parser_omp_target (and other cp/parser.c
    callers of c_omp_adjust_map_clauses) shouldn't call it only
    if (!processing_template_decl) - perhaps you could add
    cp_omp_adjust_map_clauses wrapper that would be
    if (!processing_template_decl)
      c_omp_adjust_map_clauses (...);
    - and call c_omp_adjust_map_clauses from within pt.c after the clauses
    are tsubsted and finish_omp_clauses is called again.

    2021-06-06  Jakub Jelinek  <jakub@redhat.com>

            PR c/100902
            * c-parser.c (c_parser_omp_target): Call c_omp_adjust_map_clauses
            even when target is combined with other constructs.

            * parser.c (cp_parser_omp_target): Call c_omp_adjust_map_clauses
            even when target is combined with other constructs.

            * c-c++-common/gomp/pr100902-1.c: New test.

[Bug c/100902] pointer attachment issues

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:132d3e9d57a522792e300d4c8a91e9d1b8ef5577

commit r11-8588-g132d3e9d57a522792e300d4c8a91e9d1b8ef5577
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun Jun 6 19:37:06 2021 +0200

    openmp: Call c_omp_adjust_map_clauses even for combined target [PR100902]

    When looking at in_reduction support for target, I've noticed that
    c_omp_adjust_map_clauses is not called for the combined target case.

    The following patch fixes it.

    Unfortunately, there are other issues.

    One is (also mentioned in the PR) that currently the pointer attachment
    stuff seems to be clause ordering dependent (the standard says that clause
    ordering on the same construct does not matter), the baz and qux cases
    in the PR are rejected while when swapped it is accepted.
    Note, the order of clauses in GCC really is treated as insignificant
    initially and only later on the compiler can adjust the ordering (e.g. when
    we sort map clauses based on what they refer to etc.) and in particular,
    clauses from parsing is reverse of the order in user code, while
    c_omp_split_clauses performed for combined/composite constructs typically
    reverses that ordering, i.e. makes it follow the user code ordering.

    And another one is I'm slightly afraid c_omp_adjust_map_clauses might
    misbehave in templates, though haven't tried to verify it with testcases.
    When processing_template_decl, the non-dependent clauses will be handled
    usually the same as when not in a template, but dependent clauses aren't
    processed or only limited processing is done there, and rest is deferred
    till later.  From quick skimming of c_omp_adjust_map_clauses, it seems
    it might not be very happy about non-processed map clauses that might
    still have the TREE_LIST representation of array sections, or might
    not have finalized decls or base decls etc.
    So, for this I wonder if cp_parser_omp_target (and other cp/parser.c
    callers of c_omp_adjust_map_clauses) shouldn't call it only
    if (!processing_template_decl) - perhaps you could add
    cp_omp_adjust_map_clauses wrapper that would be
    if (!processing_template_decl)
      c_omp_adjust_map_clauses (...);
    - and call c_omp_adjust_map_clauses from within pt.c after the clauses
    are tsubsted and finish_omp_clauses is called again.

    2021-06-06  Jakub Jelinek  <jakub@redhat.com>

            PR c/100902
            * c-parser.c (c_parser_omp_target): Call c_omp_adjust_map_clauses
            even when target is combined with other constructs.

            * parser.c (cp_parser_omp_target): Call c_omp_adjust_map_clauses
            even when target is combined with other constructs.

            * c-c++-common/gomp/pr100902-1.c: New test.

    (cherry picked from commit 7fa4db39b6bcd207bd2bffff52023ff6b155bd15)

[Bug c/100902] pointer attachment issues

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.