From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1709) id E294C3851C02; Thu, 10 Jun 2021 12:47:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E294C3851C02 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Chung-Lin Tang To: gcc-cvs@gcc.gnu.org Subject: [gcc/devel/omp/gcc-11] openmp: Call c_omp_adjust_map_clauses even for combined target [PR100902] X-Act-Checkin: gcc X-Git-Author: Jakub Jelinek X-Git-Refname: refs/heads/devel/omp/gcc-11 X-Git-Oldrev: 82c10cefb5e1fe508194fa4fb1773c1eab2d516d X-Git-Newrev: fa0f91ce548ace32940ea4e0a1b6b36627144c94 Message-Id: <20210610124749.E294C3851C02@sourceware.org> Date: Thu, 10 Jun 2021 12:47:49 +0000 (GMT) X-BeenThere: gcc-cvs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 12:47:50 -0000 https://gcc.gnu.org/g:fa0f91ce548ace32940ea4e0a1b6b36627144c94 commit fa0f91ce548ace32940ea4e0a1b6b36627144c94 Author: Jakub Jelinek 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 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) Diff: --- gcc/c/c-parser.c | 1 + gcc/cp/parser.c | 1 + gcc/testsuite/c-c++-common/gomp/pr100902-1.c | 17 +++++++++++++++++ 3 files changed, 19 insertions(+) diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index a99e3bf4bae..286d45e4ace 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -20181,6 +20181,7 @@ c_parser_omp_target (c_parser *parser, enum pragma_context context, bool *if_p) tree stmt = make_node (OMP_TARGET); TREE_TYPE (stmt) = void_type_node; OMP_TARGET_CLAUSES (stmt) = cclauses[C_OMP_CLAUSE_SPLIT_TARGET]; + c_omp_adjust_map_clauses (OMP_TARGET_CLAUSES (stmt), true); OMP_TARGET_BODY (stmt) = block; OMP_TARGET_COMBINED (stmt) = 1; SET_EXPR_LOCATION (stmt, loc); diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 9f11e5c15fe..89eed507880 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -42243,6 +42243,7 @@ cp_parser_omp_target (cp_parser *parser, cp_token *pragma_tok, cclauses[C_OMP_CLAUSE_SPLIT_TARGET] = tc; } } + c_omp_adjust_map_clauses (cclauses[C_OMP_CLAUSE_SPLIT_TARGET], true); finish_omp_target (pragma_tok->location, cclauses[C_OMP_CLAUSE_SPLIT_TARGET], body, true); return true; diff --git a/gcc/testsuite/c-c++-common/gomp/pr100902-1.c b/gcc/testsuite/c-c++-common/gomp/pr100902-1.c new file mode 100644 index 00000000000..babd01aa6f7 --- /dev/null +++ b/gcc/testsuite/c-c++-common/gomp/pr100902-1.c @@ -0,0 +1,17 @@ +/* PR c/100902 */ + +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; +}