From: Thomas Schwinge <thomas@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>, <gcc-patches@gcc.gnu.org>
Cc: Julian Brown <julian@codesourcery.com>
Subject: Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095] (was: [PATCH 1/4] Add function for pretty-printing OpenACC clause names)
Date: Thu, 17 Feb 2022 13:33:45 +0100 [thread overview]
Message-ID: <875ypdpt92.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <878spiw84d.fsf@euler.schwinge.homeip.net>
[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]
Hi!
On 2019-10-18T14:28:18+0200, I wrote:
> On 2019-10-06T15:32:34-0700, Julian Brown <julian@codesourcery.com> wrote:
>> This patch adds a function to pretty-print OpenACC clause names from
>> OMP_CLAUSE_MAP_KINDs, for error output.
>
> Indeed talking about (OpenMP) 'map' clauses in an OpenACC context is not
> quite ideal -- that's what PR65095 is about
>> Previously approved as part of:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01292.html
> A few more comments, for later:
>
>> gcc/c-family/c-common.h | 1 +
>> gcc/c-family/c-omp.c | 33 +++++++++++++++++++++++++++++++++
>
> As I'd mentioned before: 'Eventually (that is, later), this should move
> into generic code, next to the other "clause printing".
As part of an ICE bug fix that I'm working on, I now need to use
this in GCC middle end code. Once tested, OK to push the attached
"Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]"?
Grüße
Thomas
> Also to be
> shared with Fortran.'
>
>> --- a/gcc/c-family/c-omp.c
>> +++ b/gcc/c-family/c-omp.c
>
>> +/* For OpenACC, the OMP_CLAUSE_MAP_KIND of an OMP_CLAUSE_MAP is used internally
>> + to distinguish clauses as seen by the user. Return the "friendly" clause
>> + name for error messages etc., where possible. See also
>> + c/c-parser.c:c_parser_oacc_data_clause and
>> + cp/parser.c:cp_parser_oacc_data_clause. */
>> +
>> +const char *
>> +c_omp_map_clause_name (tree clause, bool oacc)
>> +{
>> + if (oacc && OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_MAP)
>> + switch (OMP_CLAUSE_MAP_KIND (clause))
>> + {
>> + case GOMP_MAP_FORCE_ALLOC:
>> + case GOMP_MAP_ALLOC: return "create";
>> + case GOMP_MAP_FORCE_TO:
>> + case GOMP_MAP_TO: return "copyin";
>> + case GOMP_MAP_FORCE_FROM:
>> + case GOMP_MAP_FROM: return "copyout";
>> + case GOMP_MAP_FORCE_TOFROM:
>> + case GOMP_MAP_TOFROM: return "copy";
>> + case GOMP_MAP_RELEASE: return "delete";
>> + case GOMP_MAP_FORCE_PRESENT: return "present";
>> + case GOMP_MAP_ATTACH: return "attach";
>> + case GOMP_MAP_FORCE_DETACH:
>> + case GOMP_MAP_DETACH: return "detach";
>> + case GOMP_MAP_DEVICE_RESIDENT: return "device_resident";
>> + case GOMP_MAP_LINK: return "link";
>> + case GOMP_MAP_FORCE_DEVICEPTR: return "deviceptr";
>> + default: break;
>> + }
>> + return omp_clause_code_name[OMP_CLAUSE_CODE (clause)];
>> +}
>
> Indeed nearby (after) the 'omp_clause_code_name' definition in
> 'gcc/tree.c' would probably be a better place for this, as that's where
> the current clause names are coming from.
>
> I did wonder whether we need to explicitly translate from (OpenMP) "'map'
> clause" into (OpenACC) "'create' clause" etc., or if a generic (OpenACC)
> "data clause" would be sufficient? (After all, in diagnostics we also
> print out the original code, so the user can then see which specific data
> clause is being complained about. But -- somewhat funnily! -- the way
> you're doing this might actually be better in terms of translatability in
> diagnostics printing: "%qs clause" might require a different translation
> when its "%s" can be "'map'" (doesn't get translated) vs. "data" (gets
> translated), but remains the same when "%s" is "'map'" vs. "'create'"
> etc.
>
> Do we at all still generate 'GOMP_MAP_FORCE_*' anywhere, or should these
> in fact be 'gcc_unreachable'?
>
> Generally, I prefer if all possible 'case's are listed explicitly, and
> then the 'default' (and here OpenMP-only ones, too) be 'gcc_unreachable',
> so that we easily catch the case that new 'GOMP_MAP_*' get added but such
> functions not updated, for example.
>
>
> Grüße
> Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-gcc-tree.cc-user_omp_clause_code_name-PR65095.patch --]
[-- Type: text/x-diff, Size: 6865 bytes --]
From 741a15e861fb97f720d527f917b5888c2b9324e9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Thu, 17 Feb 2022 12:46:57 +0100
Subject: [PATCH] Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]
Re PR65095 "Adapt OpenMP diagnostic messages for OpenACC", move
'gcc/c-family/c-omp.cc:c_omp_map_clause_name' C/C++ front end to
'gcc/tree.cc:user_omp_clause_code_name' middle end. No functional change.
PR other/65095
TODO
---
gcc/c-family/c-common.h | 1 -
gcc/c-family/c-omp.cc | 33 ---------------------------------
gcc/c/c-typeck.cc | 4 ++--
gcc/cp/semantics.cc | 4 ++--
gcc/tree-core.h | 1 +
gcc/tree.cc | 36 ++++++++++++++++++++++++++++++++++++
6 files changed, 41 insertions(+), 38 deletions(-)
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index ee0c4de2a05..09e4c378cb9 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1249,7 +1249,6 @@ extern enum omp_clause_default_kind c_omp_predetermined_sharing (tree);
extern enum omp_clause_defaultmap_kind c_omp_predetermined_mapping (tree);
extern tree c_omp_check_context_selector (location_t, tree);
extern void c_omp_mark_declare_variant (location_t, tree, tree);
-extern const char *c_omp_map_clause_name (tree, bool);
extern void c_omp_adjust_map_clauses (tree, bool);
enum c_omp_directive_kind {
diff --git a/gcc/c-family/c-omp.cc b/gcc/c-family/c-omp.cc
index cd9d86641e1..777cdc65572 100644
--- a/gcc/c-family/c-omp.cc
+++ b/gcc/c-family/c-omp.cc
@@ -2996,39 +2996,6 @@ c_omp_predetermined_mapping (tree decl)
}
-/* For OpenACC, the OMP_CLAUSE_MAP_KIND of an OMP_CLAUSE_MAP is used internally
- to distinguish clauses as seen by the user. Return the "friendly" clause
- name for error messages etc., where possible. See also
- c/c-parser.cc:c_parser_oacc_data_clause and
- cp/parser.cc:cp_parser_oacc_data_clause. */
-
-const char *
-c_omp_map_clause_name (tree clause, bool oacc)
-{
- if (oacc && OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_MAP)
- switch (OMP_CLAUSE_MAP_KIND (clause))
- {
- case GOMP_MAP_FORCE_ALLOC:
- case GOMP_MAP_ALLOC: return "create";
- case GOMP_MAP_FORCE_TO:
- case GOMP_MAP_TO: return "copyin";
- case GOMP_MAP_FORCE_FROM:
- case GOMP_MAP_FROM: return "copyout";
- case GOMP_MAP_FORCE_TOFROM:
- case GOMP_MAP_TOFROM: return "copy";
- case GOMP_MAP_RELEASE: return "delete";
- case GOMP_MAP_FORCE_PRESENT: return "present";
- case GOMP_MAP_ATTACH: return "attach";
- case GOMP_MAP_FORCE_DETACH:
- case GOMP_MAP_DETACH: return "detach";
- case GOMP_MAP_DEVICE_RESIDENT: return "device_resident";
- case GOMP_MAP_LINK: return "link";
- case GOMP_MAP_FORCE_DEVICEPTR: return "deviceptr";
- default: break;
- }
- return omp_clause_code_name[OMP_CLAUSE_CODE (clause)];
-}
-
/* Used to merge map clause information in c_omp_adjust_map_clauses. */
struct map_clause
{
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 61bc4f6efe7..2b3773a4303 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -13368,7 +13368,7 @@ handle_omp_array_sections_1 (tree c, tree t, vec<tree> &types,
{
error_at (OMP_CLAUSE_LOCATION (c),
"expected single pointer in %qs clause",
- c_omp_map_clause_name (c, ort == C_ORT_ACC));
+ user_omp_clause_code_name (c, ort == C_ORT_ACC));
return error_mark_node;
}
}
@@ -14091,7 +14091,7 @@ c_oacc_check_attachments (tree c)
if (TREE_CODE (TREE_TYPE (t)) != POINTER_TYPE)
{
error_at (OMP_CLAUSE_LOCATION (c), "expected pointer in %qs clause",
- c_omp_map_clause_name (c, true));
+ user_omp_clause_code_name (c, true));
return true;
}
}
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 066320e9b7c..7666b08f518 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -5199,7 +5199,7 @@ handle_omp_array_sections_1 (tree c, tree t, vec<tree> &types,
{
error_at (OMP_CLAUSE_LOCATION (c),
"expected single pointer in %qs clause",
- c_omp_map_clause_name (c, ort == C_ORT_ACC));
+ user_omp_clause_code_name (c, ort == C_ORT_ACC));
return error_mark_node;
}
}
@@ -6657,7 +6657,7 @@ cp_oacc_check_attachments (tree c)
if (TREE_CODE (type) != POINTER_TYPE)
{
error_at (OMP_CLAUSE_LOCATION (c), "expected pointer in %qs clause",
- c_omp_map_clause_name (c, true));
+ user_omp_clause_code_name (c, true));
return true;
}
}
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index 2682d2ceb7f..61106f2a49b 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -2270,6 +2270,7 @@ extern const char * built_in_names[(int) END_BUILTINS];
/* Number of operands and names for each OMP_CLAUSE node. */
extern unsigned const char omp_clause_num_ops[];
extern const char * const omp_clause_code_name[];
+extern const char *user_omp_clause_code_name (tree, bool);
/* A vector of all translation-units. */
extern GTY (()) vec<tree, va_gc> *all_translation_units;
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 307b1f6b0b3..95226781b4e 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -69,6 +69,7 @@ along with GCC; see the file COPYING3. If not see
#include "gimple-fold.h"
#include "escaped_string.h"
#include "gimple-range.h"
+#include "gomp-constants.h"
/* Tree code classes. */
@@ -456,6 +457,41 @@ const char * const omp_clause_code_name[] =
"nohost",
};
+/* Unless specific to OpenACC, we tend to internally maintain OpenMP-centric
+ clause names, but for use in diagnostics etc. would like to use the "user"
+ clause names. */
+
+const char *
+user_omp_clause_code_name (tree clause, bool oacc)
+{
+ /* For OpenACC, the 'OMP_CLAUSE_MAP_KIND' of an 'OMP_CLAUSE_MAP' is used to
+ distinguish clauses as seen by the user. See also where front ends do
+ 'build_omp_clause' with 'OMP_CLAUSE_MAP'. */
+ if (oacc && OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_MAP)
+ switch (OMP_CLAUSE_MAP_KIND (clause))
+ {
+ case GOMP_MAP_FORCE_ALLOC:
+ case GOMP_MAP_ALLOC: return "create";
+ case GOMP_MAP_FORCE_TO:
+ case GOMP_MAP_TO: return "copyin";
+ case GOMP_MAP_FORCE_FROM:
+ case GOMP_MAP_FROM: return "copyout";
+ case GOMP_MAP_FORCE_TOFROM:
+ case GOMP_MAP_TOFROM: return "copy";
+ case GOMP_MAP_RELEASE: return "delete";
+ case GOMP_MAP_FORCE_PRESENT: return "present";
+ case GOMP_MAP_ATTACH: return "attach";
+ case GOMP_MAP_FORCE_DETACH:
+ case GOMP_MAP_DETACH: return "detach";
+ case GOMP_MAP_DEVICE_RESIDENT: return "device_resident";
+ case GOMP_MAP_LINK: return "link";
+ case GOMP_MAP_FORCE_DEVICEPTR: return "deviceptr";
+ default: break;
+ }
+
+ return omp_clause_code_name[OMP_CLAUSE_CODE (clause)];
+}
+
/* Return the tree node structure used by tree code CODE. */
--
2.34.1
next prev parent reply other threads:[~2022-02-17 12:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-06 22:32 [PATCH 0/4] OpenACC 2.6 manual deep copy (repost) Julian Brown
2019-10-06 22:33 ` [PATCH 1/4] Add function for pretty-printing OpenACC clause names Julian Brown
2019-10-18 12:44 ` Thomas Schwinge
2022-02-17 12:33 ` Thomas Schwinge [this message]
2022-03-12 10:11 ` Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095] Thomas Schwinge
2019-10-06 22:33 ` [PATCH 3/4] Factor out duplicate code in gimplify_scan_omp_clauses Julian Brown
2019-10-16 14:43 ` Thomas Schwinge
2019-11-05 16:42 ` Julian Brown
2019-10-06 22:33 ` [PATCH 4/4] OpenACC 2.6 manual deep copy support (attach/detach) Julian Brown
2019-10-06 22:33 ` [PATCH 2/4] Use gomp_map_val for OpenACC host-to-device address translation Julian Brown
2019-10-16 9:34 ` Thomas Schwinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875ypdpt92.fsf@euler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=julian@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).