Re: [patch] OpenACC fortran front end

[Jakub Jelinek]

On Fri, Nov 14, 2014 at 08:56:53AM +0100, Thomas Schwinge wrote:
 Hi!
 
 On Thu, 13 Nov 2014 17:44:40 -0800, Cesar Philippidis 
 ce...@codesourcery.com wrote:
  On 11/13/2014 08:43 AM, Jakub Jelinek wrote:
   Can you please avoid the TODOs in the source?  If it is not the right
   thing, either do something better, or file a PR to schedule such work for
   the future.
 
 Should we use the existing openmp keyword for this,
 https://gcc.gnu.org/bugzilla/describekeywords.cgi, or get a new openacc
 keyword added?

Please add openacc.

Jakub

Re: [patch] OpenACC fortran front end

[Thomas Schwinge]

Hi!

On Fri, 14 Nov 2014 09:33:13 +0100, Jakub Jelinek ja...@redhat.com wrote:
 On Fri, Nov 14, 2014 at 08:56:53AM +0100, Thomas Schwinge wrote:
  On Thu, 13 Nov 2014 17:44:40 -0800, Cesar Philippidis 
  ce...@codesourcery.com wrote:
   On 11/13/2014 08:43 AM, Jakub Jelinek wrote:
Can you please avoid the TODOs in the source?  If it is not the right
thing, either do something better, or file a PR to schedule such work 
for
the future.
  
  Should we use the existing openmp keyword for this,
  https://gcc.gnu.org/bugzilla/describekeywords.cgi, or get a new openacc
  keyword added?
 
 Please add openacc.

Turns out that I could do that myself --
https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=openacc created.


Grüße,
 Thomas


pgptnEphu_gNv.pgp
Description: PGP signature

openacc Bugzilla keyword (was: [patch] OpenACC fortran front end)

[Thomas Schwinge]

Hi!

On Fri, 14 Nov 2014 10:21:47 +0100, I wrote:
 https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=openacc created.

Committed to gomp-4_0-branch in r217549:

commit 4a4f1ca48781ac08d2d51ba1a08210d8c8ca7528
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date:   Fri Nov 14 10:19:53 2014 +

libgomp documentation, Reporting Bug: Mention the openacc Bugzilla 
keyword.

libgomp/
* libgomp.texi (Reporting Bugs): Mention the openacc Bugzilla
keyword.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@217549 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog.gomp | 5 +
 libgomp/libgomp.texi   | 5 +++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git libgomp/ChangeLog.gomp libgomp/ChangeLog.gomp
index a5a58a0..492393b 100644
--- libgomp/ChangeLog.gomp
+++ libgomp/ChangeLog.gomp
@@ -1,3 +1,8 @@
+2014-11-14  Thomas Schwinge  tho...@codesourcery.com
+
+   * libgomp.texi (Reporting Bugs): Mention the openacc Bugzilla
+   keyword.
+
 2014-11-13  Thomas Schwinge  tho...@codesourcery.com
 
* testsuite/libgomp.oacc-c-c++-common/context-2.c: Fix data
diff --git libgomp/libgomp.texi libgomp/libgomp.texi
index 26c65a6..6c2673b 100644
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -2686,8 +2686,9 @@ becomes
 @chapter Reporting Bugs
 
 Bugs in the GNU OpenACC or OpenMP implementation should be reported via
-@uref{http://gcc.gnu.org/bugzilla/, Bugzilla}.  For OpenMP cases, please add
-openmp to the keywords field in the bug report.
+@uref{http://gcc.gnu.org/bugzilla/, Bugzilla}.  As appropriate, please
+add openacc, or openmp, or both to the keywords field in the bug
+report.
 
 
 


Grüße,
 Thomas


pgpBd1QzTGJdS.pgp
Description: PGP signature

Re: [patch] OpenACC fortran front end

[Joseph Myers]

On Fri, 14 Nov 2014, Jakub Jelinek wrote:

 You want
   gfc_error (is_oacc (p)
  ? %s statement at %C leaving OpenACC structured block
  : %s statement at %C leaving OpenMP structured block,
  gfc_ascii_statement (st));
 instead to be more translation friendly.

Does gettext now extract both halves of a conditional expression?  At 
least at one point it was necessary to use an if statement, or mark up 
both strings with G_() to get them extracted.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch] OpenACC fortran front end

[Jakub Jelinek]

On Thu, Nov 06, 2014 at 02:25:52PM -0800, Cesar Philippidis wrote:
   * cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
   * dump-parse-tree.c
   (show_omp_node): Dump also OpenACC executable statements.

Put (show_omp_node): ... and what fits on the same line as *
dump-parse-tree.c, don't wrap prematurely.

 +#undef DEF_GOACC_BUILTIN_COMPILER
 +  /* TODO: this is not doing the right thing.  */

Can you please avoid the TODOs in the source?  If it is not the right
thing, either do something better, or file a PR to schedule such work for
the future.

 +  struct gfc_expr *gang_expr;
 +  struct gfc_expr *worker_expr;
 +  struct gfc_expr *vector_expr;
 +  struct gfc_expr *num_gangs_expr;
 +  struct gfc_expr *num_workers_expr;
 +  struct gfc_expr *vector_length_expr;
 +  gfc_expr_list *wait_list;
 +  gfc_expr_list *tile_list;
 +  unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1;
 +  unsigned wait:1, par_auto:1, gang_static:1;
 +
 +  /* Directive specific data.  */
 +  union
 +  {
 +/* !$ACC DECLARE locus.  */
 +locus loc;
 +  }
 +  ext;

Perhaps turn it into a union only when you have more than one field?
And if we start to use unions, I bet we should do something with having
such huge struct with most of the empty pointers anyway, add some hierarchy
to those.

 --- a/gcc/fortran/match.c
 +++ b/gcc/fortran/match.c
 @@ -2491,7 +2491,7 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
  
if (o != NULL)
  {
 -  gfc_error (%s statement at %C leaving OpenMP structured block,
 +  gfc_error (%s statement at %C leaving OpenMP or OpenACC structured 
 block,
gfc_ascii_statement (st));
return MATCH_ERROR;
  }

I think it would be better to specify which (ie. compute
is_oacc and have two different format strings, is_oacc ?  ...  :  ... ).

 -/* Match OpenMP directive clauses. MASK is a bitmask of
 +/* OpenACC 2.0 clauses. */
 +#define OMP_CLAUSE_ASYNC (1ULL  32)

As C++98 doesn't mandate long long type, I'm afraid we shouldn't use
1ULL; we require some 64-bit type though, so perhaps just use
((uint64_t) 1  32) etc.?

 +#define OMP_CLAUSE_NUM_GANGS (1ULL  33)
 +#define OMP_CLAUSE_NUM_WORKERS   (1ULL  34)
 +#define OMP_CLAUSE_VECTOR_LENGTH (1ULL  35)
 +#define OMP_CLAUSE_COPY  (1ULL  36)
 +#define OMP_CLAUSE_COPYOUT   (1ULL  37)
 +#define OMP_CLAUSE_CREATE(1ULL  38)
 +#define OMP_CLAUSE_PRESENT   (1ULL  39)
 +#define OMP_CLAUSE_PRESENT_OR_COPY   (1ULL  40)
 +#define OMP_CLAUSE_PRESENT_OR_COPYIN (1ULL  41)
 +#define OMP_CLAUSE_PRESENT_OR_COPYOUT(1ULL  42)
 +#define OMP_CLAUSE_PRESENT_OR_CREATE (1ULL  43)
 +#define OMP_CLAUSE_DEVICEPTR (1ULL  44)
 +#define OMP_CLAUSE_GANG  (1ULL  45)
 +#define OMP_CLAUSE_WORKER(1ULL  46)
 +#define OMP_CLAUSE_VECTOR(1ULL  47)
 +#define OMP_CLAUSE_SEQ   (1ULL  48)
 +#define OMP_CLAUSE_INDEPENDENT   (1ULL  49)
 +#define OMP_CLAUSE_USE_DEVICE(1ULL  50)
 +#define OMP_CLAUSE_DEVICE_RESIDENT   (1ULL  51)
 +#define OMP_CLAUSE_HOST_SELF (1ULL  52)
 +#define OMP_CLAUSE_OACC_DEVICE   (1ULL  53)
 +#define OMP_CLAUSE_WAIT  (1ULL  54)
 +#define OMP_CLAUSE_DELETE(1ULL  55)
 +#define OMP_CLAUSE_AUTO  (1ULL  56)
 +#define OMP_CLAUSE_TILE  (1ULL  57)

  static match
 -gfc_match_omp_clauses (gfc_omp_clauses **cp, unsigned int mask,
 -bool first = true, bool needs_space = true)
 +gfc_match_omp_clauses (gfc_omp_clauses **cp, unsigned long long mask,
 +bool first = true, bool needs_space = true,

See above, use uint64_t.

 + c-async_expr = gfc_get_constant_expr (BT_INTEGER,
 +gfc_default_integer_kind,
 +   gfc_current_locus);
 + /* TODO XXX: FIX -1 (acc_async_noval).  */

Please use gomp-constants.h for this, or some other enum, and avoid
TODO XXX comments in the source.

 +static gfc_statement
 +omp_code_to_statement (gfc_code *code)
 +{
 +switch (code-op)
 +  {
 +  case EXEC_OMP_PARALLEL:
 +return ST_OMP_PARALLEL;

Wrong formatting.  switch should be indented by 2 spaces, { after it by 4,
case by 4 too and return by 6 spaces.

 +  default:
 +gcc_unreachable ();
 +  }
...

 +oacc_code_to_statement (gfc_code *code)
 +{
 +switch (code-op)
 +  {

Likewise here.

 +static void
 +resolve_oacc_loop(gfc_code *code)

Formatting - missing space before (, please check it everywhere.

 +static void
 +resolve_oacc_cache (gfc_code *code)
 +{
 +  gfc_error (Sorry, !$ACC cache unimplemented yet at %L, code-loc);

Shouldn't this be sorry (...) instead?

 +}
 +
 +
 +void
 +gfc_resolve_oacc_declare (gfc_namespace *ns)
 +{
 +  int list;
 +  gfc_omp_namelist *n;
 +  locus loc;
 +  

Re: [patch] OpenACC fortran front end

[Cesar Philippidis]

On 11/13/2014 08:43 AM, Jakub Jelinek wrote:

 On Thu, Nov 06, 2014 at 02:25:52PM -0800, Cesar Philippidis wrote:
  * cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
  * dump-parse-tree.c
  (show_omp_node): Dump also OpenACC executable statements.
 
 Put (show_omp_node): ... and what fits on the same line as *
 dump-parse-tree.c, don't wrap prematurely.
 
 +#undef DEF_GOACC_BUILTIN_COMPILER
 +  /* TODO: this is not doing the right thing.  */
 
 Can you please avoid the TODOs in the source?  If it is not the right
 thing, either do something better, or file a PR to schedule such work for
 the future.
 
 +  struct gfc_expr *gang_expr;
 +  struct gfc_expr *worker_expr;
 +  struct gfc_expr *vector_expr;
 +  struct gfc_expr *num_gangs_expr;
 +  struct gfc_expr *num_workers_expr;
 +  struct gfc_expr *vector_length_expr;
 +  gfc_expr_list *wait_list;
 +  gfc_expr_list *tile_list;
 +  unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1;
 +  unsigned wait:1, par_auto:1, gang_static:1;
 +
 +  /* Directive specific data.  */
 +  union
 +  {
 +/* !$ACC DECLARE locus.  */
 +locus loc;
 +  }
 +  ext;
 
 Perhaps turn it into a union only when you have more than one field?
 And if we start to use unions, I bet we should do something with having
 such huge struct with most of the empty pointers anyway, add some hierarchy
 to those.
 
 --- a/gcc/fortran/match.c
 +++ b/gcc/fortran/match.c
 @@ -2491,7 +2491,7 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
  
if (o != NULL)
  {
 -  gfc_error (%s statement at %C leaving OpenMP structured block,
 +  gfc_error (%s statement at %C leaving OpenMP or OpenACC structured 
 block,
   gfc_ascii_statement (st));
return MATCH_ERROR;
  }
 
 I think it would be better to specify which (ie. compute
 is_oacc and have two different format strings, is_oacc ?  ...  :  ... ).
 
 -/* Match OpenMP directive clauses. MASK is a bitmask of
 +/* OpenACC 2.0 clauses. */
 +#define OMP_CLAUSE_ASYNC(1ULL  32)
 
 As C++98 doesn't mandate long long type, I'm afraid we shouldn't use
 1ULL; we require some 64-bit type though, so perhaps just use
 ((uint64_t) 1  32) etc.?
 
 +#define OMP_CLAUSE_NUM_GANGS(1ULL  33)
 +#define OMP_CLAUSE_NUM_WORKERS  (1ULL  34)
 +#define OMP_CLAUSE_VECTOR_LENGTH(1ULL  35)
 +#define OMP_CLAUSE_COPY (1ULL  36)
 +#define OMP_CLAUSE_COPYOUT  (1ULL  37)
 +#define OMP_CLAUSE_CREATE   (1ULL  38)
 +#define OMP_CLAUSE_PRESENT  (1ULL  39)
 +#define OMP_CLAUSE_PRESENT_OR_COPY  (1ULL  40)
 +#define OMP_CLAUSE_PRESENT_OR_COPYIN(1ULL  41)
 +#define OMP_CLAUSE_PRESENT_OR_COPYOUT   (1ULL  42)
 +#define OMP_CLAUSE_PRESENT_OR_CREATE(1ULL  43)
 +#define OMP_CLAUSE_DEVICEPTR(1ULL  44)
 +#define OMP_CLAUSE_GANG (1ULL  45)
 +#define OMP_CLAUSE_WORKER   (1ULL  46)
 +#define OMP_CLAUSE_VECTOR   (1ULL  47)
 +#define OMP_CLAUSE_SEQ  (1ULL  48)
 +#define OMP_CLAUSE_INDEPENDENT  (1ULL  49)
 +#define OMP_CLAUSE_USE_DEVICE   (1ULL  50)
 +#define OMP_CLAUSE_DEVICE_RESIDENT  (1ULL  51)
 +#define OMP_CLAUSE_HOST_SELF(1ULL  52)
 +#define OMP_CLAUSE_OACC_DEVICE  (1ULL  53)
 +#define OMP_CLAUSE_WAIT (1ULL  54)
 +#define OMP_CLAUSE_DELETE   (1ULL  55)
 +#define OMP_CLAUSE_AUTO (1ULL  56)
 +#define OMP_CLAUSE_TILE (1ULL  57)
 
  static match
 -gfc_match_omp_clauses (gfc_omp_clauses **cp, unsigned int mask,
 -   bool first = true, bool needs_space = true)
 +gfc_match_omp_clauses (gfc_omp_clauses **cp, unsigned long long mask,
 +   bool first = true, bool needs_space = true,
 
 See above, use uint64_t.
 
 +c-async_expr = gfc_get_constant_expr (BT_INTEGER,
 +   gfc_default_integer_kind,
 +  gfc_current_locus);
 +/* TODO XXX: FIX -1 (acc_async_noval).  */
 
 Please use gomp-constants.h for this, or some other enum, and avoid
 TODO XXX comments in the source.

Thomas told me that he fix this when he updates gomp-constants.h.

 +static gfc_statement
 +omp_code_to_statement (gfc_code *code)
 +{
 +switch (code-op)
 +  {
 +  case EXEC_OMP_PARALLEL:
 +return ST_OMP_PARALLEL;
 
 Wrong formatting.  switch should be indented by 2 spaces, { after it by 4,
 case by 4 too and return by 6 spaces.
 
 +  default:
 +gcc_unreachable ();
 +  }
 ...
 
 +oacc_code_to_statement (gfc_code *code)
 +{
 +switch (code-op)
 +  {
 
 Likewise here.
 
 +static void
 +resolve_oacc_loop(gfc_code *code)
 
 Formatting - missing space before (, please check it everywhere.
 
 +static void
 +resolve_oacc_cache (gfc_code *code)
 +{
 +  gfc_error (Sorry, !$ACC cache unimplemented yet at %L, code-loc);
 
 

Re: [patch] OpenACC fortran front end

[Jakub Jelinek]

On Thu, Nov 13, 2014 at 05:44:40PM -0800, Cesar Philippidis wrote:
 Thanks. I couldn't figure out how to assign the bugs in the PR. Maybe my
 account doesn't have permission to do so. Regardless, I'll work on them.

Use your @gcc.gnu.org account instead, then you have far more permissions
in bugzilla.

 --- a/gcc/fortran/gfortran.h
 +++ b/gcc/fortran/gfortran.h
 @@ -1262,14 +1262,8 @@ typedef struct gfc_omp_clauses
gfc_expr_list *tile_list;
unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1;
unsigned wait:1, par_auto:1, gang_static:1;

The /* !$ACC DECLARE locus.  */ comment wouldn't hurt here.

 --- a/gcc/fortran/match.c
 +++ b/gcc/fortran/match.c
 @@ -2491,8 +2491,8 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
  
if (o != NULL)
  {
 -  gfc_error (%s statement at %C leaving OpenMP or OpenACC structured 
 block,
 -  gfc_ascii_statement (st));
 +  gfc_error (%s statement at %C leaving %s structured block,
 +  gfc_ascii_statement (st), is_oacc (p) ? OpenACC : OpenMP);

You want
gfc_error (is_oacc (p)
   ? %s statement at %C leaving OpenACC structured block
   : %s statement at %C leaving OpenMP structured block,
   gfc_ascii_statement (st));
instead to be more translation friendly.

 @@ -5545,3 +5547,28 @@ duplicate_main:
gfc_done_2 ();
return true;
  }
 +
 +/* Return true if this state data represents an OpenACC region.  */
 +bool
 +is_oacc (gfc_state_data *sd)
 +{
 +  switch (sd-construct-op)
 +{
 +case EXEC_OACC_PARALLEL_LOOP:break;
 +case EXEC_OACC_PARALLEL:

What is that break; doing there?  Then you fall through into end of function
without return (and missing space before it).

 +case EXEC_OACC_KERNELS_LOOP:
 +case EXEC_OACC_KERNELS:
 +case EXEC_OACC_DATA:
 +case EXEC_OACC_HOST_DATA:
 +case EXEC_OACC_LOOP:
 +case EXEC_OACC_UPDATE:
 +case EXEC_OACC_WAIT:
 +case EXEC_OACC_CACHE:
 +case EXEC_OACC_ENTER_DATA:
 +case EXEC_OACC_EXIT_DATA:
 +  return true;
 +
 +default:
 +  return false;
 +}
 +}

Jakub

Re: [patch] OpenACC fortran front end

[Cesar Philippidis]

On 11/13/2014 10:52 PM, Jakub Jelinek wrote:
 On Thu, Nov 13, 2014 at 05:44:40PM -0800, Cesar Philippidis wrote:
 Thanks. I couldn't figure out how to assign the bugs in the PR. Maybe my
 account doesn't have permission to do so. Regardless, I'll work on them.
 
 Use your @gcc.gnu.org account instead, then you have far more permissions
 in bugzilla.

Thanks. I'll look into that.

 --- a/gcc/fortran/gfortran.h
 +++ b/gcc/fortran/gfortran.h
 @@ -1262,14 +1262,8 @@ typedef struct gfc_omp_clauses
gfc_expr_list *tile_list;
unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1;
unsigned wait:1, par_auto:1, gang_static:1;
 
 The /* !$ACC DECLARE locus.  */ comment wouldn't hurt here.
 
 --- a/gcc/fortran/match.c
 +++ b/gcc/fortran/match.c
 @@ -2491,8 +2491,8 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
  
if (o != NULL)
  {
 -  gfc_error (%s statement at %C leaving OpenMP or OpenACC structured 
 block,
 - gfc_ascii_statement (st));
 +  gfc_error (%s statement at %C leaving %s structured block,
 + gfc_ascii_statement (st), is_oacc (p) ? OpenACC : OpenMP);
 
 You want
   gfc_error (is_oacc (p)
  ? %s statement at %C leaving OpenACC structured block
  : %s statement at %C leaving OpenMP structured block,
  gfc_ascii_statement (st));
 instead to be more translation friendly.
 
 @@ -5545,3 +5547,28 @@ duplicate_main:
gfc_done_2 ();
return true;
  }
 +
 +/* Return true if this state data represents an OpenACC region.  */
 +bool
 +is_oacc (gfc_state_data *sd)
 +{
 +  switch (sd-construct-op)
 +{
 +case EXEC_OACC_PARALLEL_LOOP:break;
 +case EXEC_OACC_PARALLEL:
 
 What is that break; doing there?  Then you fall through into end of function
 without return (and missing space before it).

It's bogus. I've applied the attach patch to gomp-4_0-branch which
addresses these two problems.

Thanks,
Cesar

2014-11-13  Cesar Philippidis  ce...@codesourcery.com

	gcc/fortran/
	* match.c (match_exit_cycle): Restructure error strings.
	* parse.c (is_oacc): Remove bogus break.

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 217532)
+++ gcc/fortran/match.c	(working copy)
@@ -2491,8 +2491,10 @@ match_exit_cycle (gfc_statement st, gfc_
 
   if (o != NULL)
 {
-  gfc_error (%s statement at %C leaving %s structured block,
-		 gfc_ascii_statement (st), is_oacc (p) ? OpenACC : OpenMP);
+  gfc_error (is_oacc (p)
+		 ? %s statement at %C leaving OpenACC structured block
+		 : %s statement at %C leaving OpenMP structured block,
+		 gfc_ascii_statement (st));
   return MATCH_ERROR;
 }
 
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c	(revision 217532)
+++ gcc/fortran/parse.c	(working copy)
@@ -5554,7 +5554,7 @@ is_oacc (gfc_state_data *sd)
 {
   switch (sd-construct-op)
 {
-case EXEC_OACC_PARALLEL_LOOP:break;
+case EXEC_OACC_PARALLEL_LOOP:
 case EXEC_OACC_PARALLEL:
 case EXEC_OACC_KERNELS_LOOP:
 case EXEC_OACC_KERNELS:

Re: [patch] OpenACC fortran front end

[Thomas Schwinge]

Hi!

On Thu, 13 Nov 2014 17:44:40 -0800, Cesar Philippidis ce...@codesourcery.com 
wrote:
 On 11/13/2014 08:43 AM, Jakub Jelinek wrote:
  Can you please avoid the TODOs in the source?  If it is not the right
  thing, either do something better, or file a PR to schedule such work for
  the future.

Should we use the existing openmp keyword for this,
https://gcc.gnu.org/bugzilla/describekeywords.cgi, or get a new openacc
keyword added?


 Using -fopenmp with -fopenacc is broken. See
 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858

Another issue: I noticed that when compiling fixed-form code such as
libgomp/testsuite/libgomp.oacc-fortran/data-already-2.f with both
-fopenacc -fopenmp, the data constructs disappear (see
-ftree-dump-original, for example).

We have a (tiny, addmittedly) little bit of testing for C/C++,
gcc/testsuite/*/*goacc-gomp, but should also to Fortran add a goacc-gomp
testsuite.


   gcc/fortran/
   * f95-lang.c (DEF_GOACC_BUILTIN_COMPILER): Remove bogus TODO.

 --- a/gcc/fortran/f95-lang.c
 +++ b/gcc/fortran/f95-lang.c
 @@ -1189,7 +1189,6 @@ gfc_init_builtin_functions (void)
gfc_define_builtin (__builtin_ name, builtin_types[type], \
 code, name, attr);
  #undef DEF_GOACC_BUILTIN_COMPILER
 -  /* TODO: this is not doing the right thing.  */
  #define DEF_GOACC_BUILTIN_COMPILER(code, name, type, attr) \
gfc_define_builtin (name, builtin_types[type], code, name, attr);
  #include ../oacc-builtins.def

(OK to not include the TODO marker in the trunk submission, but) I don't
think it's bogus, but really doesn't work, as discussed before,
http://news.gmane.org/find-root.php?message_id=%3C87k350n6zl.fsf%40schwinge.name%3E.


 --- a/gcc/fortran/parse.c
 +++ b/gcc/fortran/parse.c
 @@ -3818,7 +3818,9 @@ parse_critical_block (void)
  
for (sd = gfc_state_stack; sd; sd = sd-previous) 
  if (sd-state == COMP_OMP_STRUCTURED_BLOCK)
 -  gfc_error_now (CRITICAL block inside of OpenMP or OpenACC region at 
 %C);
 +  gfc_error_now (is_oacc (sd)
 +  ? CRITICAL block inside of OpenACC region at %C
 +  : CRITICAL block inside of OpenMP region at %C);

Can't use %s and »is_oacc () ? OpenACC : OpenMP« here, too?

 +/* Return true if this state data represents an OpenACC region.  */
 +bool
 +is_oacc (gfc_state_data *sd)
 +{
 +  switch (sd-construct-op)
 +{
 +case EXEC_OACC_PARALLEL_LOOP:break;

Misplaced break statement?  (Doesn't that result in a compiler warning,
non-void function returns, or similar?)

 +case EXEC_OACC_PARALLEL:
 +case EXEC_OACC_KERNELS_LOOP:
 +case EXEC_OACC_KERNELS:
 +case EXEC_OACC_DATA:
 +case EXEC_OACC_HOST_DATA:
 +case EXEC_OACC_LOOP:
 +case EXEC_OACC_UPDATE:
 +case EXEC_OACC_WAIT:
 +case EXEC_OACC_CACHE:
 +case EXEC_OACC_ENTER_DATA:
 +case EXEC_OACC_EXIT_DATA:
 +  return true;
 +
 +default:
 +  return false;
 +}
 +}


 --- a/gcc/testsuite/gfortran.dg/gomp/omp_do1.f90
 +++ b/gcc/testsuite/gfortran.dg/gomp/omp_do1.f90
 @@ -44,7 +44,7 @@ outer: do i = 1, 30
end do outer
  last: do i = 1, 30
  !$omp parallel
 -if (i .eq. 21) exit last ! { dg-error leaving OpenMP or OpenACC 
 structured block }
 +if (i .eq. 21) exit last ! { dg-error leaving OpenMP structured block }
  !$omp end parallel
end do last
  !$omp parallel do shared (i)

Does that suggest that we have no corresponding testing for OpenACC?


A few more issues that I noted (but this is still not a comprehensive
code review).  Not knowing which of those you'd like to address right
now, I have not yet filed any PRs.


gcc/fortran/dump-parse-tree.c:show_omp_namelist only handles the OpenMP
gcc/fortran/gfortran.h:gfc_omp_map_op OMP_MAP_* but not those that we're
adding for the OpenACC interfaces.


Doesn't gcc/fortran/frontend-passes:gfc_code_walker need to be updated
for OpenACC?


I still think (as discussed before, at the end of
http://news.gmane.org/find-root.php?message_id=%3C87a97yrjf7.fsf%40schwinge.name%3E),
that the handling of the openacc flag in
gcc/fortran/openmp.c:resolve_omp_clauses with regard to »(list !=
OMP_LIST_MAP || openacc)«, and further down, resolve_oacc_data_clauses
and resolve_oacc_deviceptr_clause is strange.


What is the purpose of gcc/fortran/gfortran.h:OMP_LIST_FIRST?  In
gcc/fortran/gfortran.h, this is made an alias to OMP_LIST_PRIVATE, which
is then, by the OMP_LIST_FIRST name, used in
gcc/fortran/openmp.c:oacc_compatible_clauses.  Should the latter just use
the OMP_LIST_PRIVATE name, and OMP_LIST_FIRST be removed?


Grüße,
 Thomas


signature.asc
Description: PGP signature

Re: [patch] OpenACC fortran front end

[Ilya Verbin]

Hi,

On 11 Nov 08:10, Jakub Jelinek wrote:
 For the middle-end and libgomp changes, can you talk to the Intel folks to
 update their git branch to latest trunk (so that you have the nvptx bits in
 there) and send middle-end and libgomp diffs against that?
 As far as I remember, most of the changes from the branch are now approved,
 they are just waiting for review of the LTO related changes in the
 middle-end (please, correct me if I've missed something).

The updated branch is here:
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload

It contains 7 common patches.
Patches 2-4 are waiting for LTO review, the others are approved.

  -- Ilya

Pending LTO review for OpenACC trunk-merge patches (was: Re: [patch] OpenACC fortran front end)

[Tobias Burnus]

Ilya Verbin wrote:
  On 11 Nov 08:10, Jakub Jelinek wrote:
   For the middle-end and libgomp changes, can you talk to the Intel folks to
   update their git branch to latest trunk (so that you have the nvptx bits in
   there) and send middle-end and libgomp diffs against that?
 As far as I remember, most of the changes from the branch are now 
 approved,
   they are just waiting for review of the LTO related changes in the
   middle-end (please, correct me if I've missed something).
  
  The updated branch is here:
  
 https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/kyukhin/gomp4-offload
  
  It contains 7 common patches.
  Patches 2-4 are waiting for LTO review, the others are approved.

Those are:

* [PATCH 2] OpenMP 4.0 offloading infrastructure: LTO streaming
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5d1dfefd7cd529998968751a46f4daf87d8300a1

Which is identical except for re-diffing to:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00299.html


* [PATCH 3] OpenMP 4.0 offloading infrastructure: Offload tables
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=06ffd7482ef4bf2b038a3a0d203b7bec586c6d17

Which has been posted at 
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00308.html


* [PATCH 4] OpenMP 4.0 offloading infrastructure: lto-wrapper
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=41d2ad0d52fb7c6cc78f6ee4fbec7781fa226c70

See https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01535.html
or rather: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01531.html


Tobias

Re: [patch] OpenACC fortran front end

[Julian Brown]

On Tue, 11 Nov 2014 08:10:29 +0100
Jakub Jelinek ja...@redhat.com wrote:

 On Mon, Nov 10, 2014 at 02:43:38PM -0800, Cesar Philippidis wrote:
   I'll post a separate patch with the fortran tests later. If
   anyone wants to test this patch, please use gomp-4_0-branch
   instead. You don't need a CUDA accelerator to use
   OpenACC, and some of the runtime tests will fail because that
   branch doesn't include the nvptx backend.
   Now that the first series of PTX target patches have been
   committed: I assume it is still true that nvptx doesn't work
   because the libgomp bits aren't in yes, isn't it?
  
  That's correct. The nvptx backend also depends on the offloading
  changes that a team from Intel is working on for the MIC target.
  But Julian should be posting the libgomp patches tomorrow, I think,
  since his changes are somewhat self-contained.
 
 For the middle-end and libgomp changes, can you talk to the Intel
 folks to update their git branch to latest trunk (so that you have
 the nvptx bits in there) and send middle-end and libgomp diffs
 against that? As far as I remember, most of the changes from the
 branch are now approved, they are just waiting for review of the LTO
 related changes in the middle-end (please, correct me if I've missed
 something).

We've been preparing new patches against trunk for the libgomp and
middle-end bits: I've now posted the former, and the latter are on
their way soon, I believe. The middle-end bits are also present on the
gomp-4_0-branch SVN branch (likewise, the libgomp pieces), and I
believe we're planning to merge the PTX bits there also now they've
been committed to trunk.

Is it really worthwhile merging our patches to yet another branch at
this stage?

Thanks,

Julian

Re: [patch] OpenACC fortran front end

[Jakub Jelinek]

On Tue, Nov 11, 2014 at 02:52:20PM +, Julian Brown wrote:
 On Tue, 11 Nov 2014 08:10:29 +0100
 Jakub Jelinek ja...@redhat.com wrote:
 
  On Mon, Nov 10, 2014 at 02:43:38PM -0800, Cesar Philippidis wrote:
I'll post a separate patch with the fortran tests later. If
anyone wants to test this patch, please use gomp-4_0-branch
instead. You don't need a CUDA accelerator to use
OpenACC, and some of the runtime tests will fail because that
branch doesn't include the nvptx backend.
Now that the first series of PTX target patches have been
committed: I assume it is still true that nvptx doesn't work
because the libgomp bits aren't in yes, isn't it?
   
   That's correct. The nvptx backend also depends on the offloading
   changes that a team from Intel is working on for the MIC target.
   But Julian should be posting the libgomp patches tomorrow, I think,
   since his changes are somewhat self-contained.
  
  For the middle-end and libgomp changes, can you talk to the Intel
  folks to update their git branch to latest trunk (so that you have
  the nvptx bits in there) and send middle-end and libgomp diffs
  against that? As far as I remember, most of the changes from the
  branch are now approved, they are just waiting for review of the LTO
  related changes in the middle-end (please, correct me if I've missed
  something).
 
 We've been preparing new patches against trunk for the libgomp and
 middle-end bits: I've now posted the former, and the latter are on
 their way soon, I believe. The middle-end bits are also present on the
 gomp-4_0-branch SVN branch (likewise, the libgomp pieces), and I
 believe we're planning to merge the PTX bits there also now they've
 been committed to trunk.
 
 Is it really worthwhile merging our patches to yet another branch at
 this stage?

The point is that the kyukhin/gomp4-offload branch is mostly reviewed now
(waiting for Richard and/or Honza now to review the last LTO bits)
and your patches have huge overlap with that, so sending patches against
trunk that implement the same thing would mean reviewing the same bits
again, and worse if there are conflicts between the two patchsets, if
both patchsets were to be approved, one couldn't be committed anyway.

Jakub

Re: [patch] OpenACC fortran front end

[Cesar Philippidis]

On 11/11/2014 08:51 AM, Jakub Jelinek wrote:

 We've been preparing new patches against trunk for the libgomp and
 middle-end bits: I've now posted the former, and the latter are on
 their way soon, I believe. The middle-end bits are also present on the
 gomp-4_0-branch SVN branch (likewise, the libgomp pieces), and I
 believe we're planning to merge the PTX bits there also now they've
 been committed to trunk.

 Is it really worthwhile merging our patches to yet another branch at
 this stage?
 
 The point is that the kyukhin/gomp4-offload branch is mostly reviewed now
 (waiting for Richard and/or Honza now to review the last LTO bits)
 and your patches have huge overlap with that, so sending patches against
 trunk that implement the same thing would mean reviewing the same bits
 again, and worse if there are conflicts between the two patchsets, if
 both patchsets were to be approved, one couldn't be committed anyway.

Just for clarification, Julian's most recent libgomp patches are built
on top of the patches in kyukhin/gomp4-offload. He even mentions so here
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00986.html.

Cesar

Re: [patch] OpenACC fortran front end

[Julian Brown]

On Tue, 11 Nov 2014 17:51:01 +0100
Jakub Jelinek ja...@redhat.com wrote:

 On Tue, Nov 11, 2014 at 02:52:20PM +, Julian Brown wrote:
  On Tue, 11 Nov 2014 08:10:29 +0100
  Jakub Jelinek ja...@redhat.com wrote:
  
  We've been preparing new patches against trunk for the libgomp and
  middle-end bits: I've now posted the former, and the latter are on
  their way soon, I believe. The middle-end bits are also present on
  the gomp-4_0-branch SVN branch (likewise, the libgomp pieces), and I
  believe we're planning to merge the PTX bits there also now they've
  been committed to trunk.
  
  Is it really worthwhile merging our patches to yet another branch at
  this stage?
 
 The point is that the kyukhin/gomp4-offload branch is mostly reviewed
 now (waiting for Richard and/or Honza now to review the last LTO bits)
 and your patches have huge overlap with that, so sending patches
 against trunk that implement the same thing would mean reviewing the
 same bits again, and worse if there are conflicts between the two
 patchsets, if both patchsets were to be approved, one couldn't be
 committed anyway.

Yeah, understood, and apologies for not making that clearer: as Cesar
mentions, my patches are meant to apply (as well as I could manage) on
top of Ilya's ones that have mostly been approved, and there should be
no overlap in functionality (Ilya's patches subsume patches 1-6 in my
previously-posted series). Our approach to branch management perhaps
hasn't been perfect here -- it didn't dawn on me until quite late in the
submission process that Intel had been working on their own branch
rather than the gomp-4_0-branch, and that the patches they would be
posting would be based on the former rather than the latter. But, we've
tried hard to accommodate the differences that have arisen in the
meantime.

Thanks,

Julian

Re: [patch] OpenACC fortran front end

[Tobias Burnus]

Cesar Philippidis wrote:

This patch adds support for OpenACC 2.0a, with some omissions, to the
fortran front end. It only contains the fortran changes from
gomp-4_0-branch, therefore the middle end and runtime changes are a
necessary prerequisite for this patch.


I'd assume that one could commit the parser changes before the 
middle-end changes, but probably waiting for the middle-end changes is 
simpler. Any idea when the FE-required ME changes will be ready?



I'll post a separate patch with the fortran tests later. If anyone wants to 
test this patch, please use gomp-4_0-branch instead. You don't need a CUDA 
accelerator to use
OpenACC, and some of the runtime tests will fail because that branch
doesn't include the nvptx backend.
Now that the first series of PTX target patches have been committed: I 
assume it is still true that nvptx doesn't work because the libgomp bits 
aren't in yes, isn't it?



Notable OpenACC omissions include support for the device_type clause and
the atomic directive. Hopefully we can get those in before 5.0 is released.
Cache seems to be also missing, if I read 
https://gcc.gnu.org/ml/fortran/2014-11/msg00025.html correctly. (Well, 
the patch itself prints sorry for it.)



All of theses changes have been approved for gomp-4_0-branch. Is this
patch OK for mainline trunk (after the runtime and middle end go in)?


Just for completeness, there are two TODO and one FIXME in the patch.


gcc/fortran/gfortran.texi:


-include OpenMP, Cray-style pointers, and several Fortran 2003 and Fortran
+include OpenACC, OpenMP, Cray-style pointers, and several Fortran 2003
+and Fortran
  2008 features, including TR 15581.  However, it is still under
  development and has a few remaining rough edges.


Not important, but I had reflown the lines after the linebreak.


I have now browsed throughg the patch and it looks good to me. Thanks to 
everyone involved for working on this.


Tobias

Re: [patch] OpenACC fortran front end

[Cesar Philippidis]

On 11/10/2014 02:08 PM, Tobias Burnus wrote:
 Cesar Philippidis wrote:
 This patch adds support for OpenACC 2.0a, with some omissions, to the
 fortran front end. It only contains the fortran changes from
 gomp-4_0-branch, therefore the middle end and runtime changes are a
 necessary prerequisite for this patch.
 
 I'd assume that one could commit the parser changes before the
 middle-end changes, but probably waiting for the middle-end changes is
 simpler. Any idea when the FE-required ME changes will be ready?

I'm not sure. I think Thomas wants to package all of those changes
together in one big middle end patch. He found a last minute ICE the
other day. Hopefully that won't delay things very long.

 I'll post a separate patch with the fortran tests later. If anyone
 wants to test this patch, please use gomp-4_0-branch instead. You
 don't need a CUDA accelerator to use
 OpenACC, and some of the runtime tests will fail because that branch
 doesn't include the nvptx backend.
 Now that the first series of PTX target patches have been committed: I
 assume it is still true that nvptx doesn't work because the libgomp bits
 aren't in yes, isn't it?

That's correct. The nvptx backend also depends on the offloading changes
that a team from Intel is working on for the MIC target. But Julian
should be posting the libgomp patches tomorrow, I think, since his
changes are somewhat self-contained.

 Notable OpenACC omissions include support for the device_type clause and
 the atomic directive. Hopefully we can get those in before 5.0 is
 released.
 Cache seems to be also missing, if I read
 https://gcc.gnu.org/ml/fortran/2014-11/msg00025.html correctly. (Well,
 the patch itself prints sorry for it.)

Yes, that's correct. I forgot to mention that.

 All of theses changes have been approved for gomp-4_0-branch. Is this
 patch OK for mainline trunk (after the runtime and middle end go in)?
 
 Just for completeness, there are two TODO and one FIXME in the patch.

 gcc/fortran/gfortran.texi:
 
 -include OpenMP, Cray-style pointers, and several Fortran 2003 and
 Fortran
 +include OpenACC, OpenMP, Cray-style pointers, and several Fortran 2003
 +and Fortran
   2008 features, including TR 15581.  However, it is still under
   development and has a few remaining rough edges.
 
 Not important, but I had reflown the lines after the linebreak.
 
 
 I have now browsed throughg the patch and it looks good to me. Thanks to
 everyone involved for working on this.

Thanks!
Cesar

Re: [patch] OpenACC fortran front end

[Jakub Jelinek]

On Mon, Nov 10, 2014 at 02:43:38PM -0800, Cesar Philippidis wrote:
  I'll post a separate patch with the fortran tests later. If anyone
  wants to test this patch, please use gomp-4_0-branch instead. You
  don't need a CUDA accelerator to use
  OpenACC, and some of the runtime tests will fail because that branch
  doesn't include the nvptx backend.
  Now that the first series of PTX target patches have been committed: I
  assume it is still true that nvptx doesn't work because the libgomp bits
  aren't in yes, isn't it?
 
 That's correct. The nvptx backend also depends on the offloading changes
 that a team from Intel is working on for the MIC target. But Julian
 should be posting the libgomp patches tomorrow, I think, since his
 changes are somewhat self-contained.

For the middle-end and libgomp changes, can you talk to the Intel folks to
update their git branch to latest trunk (so that you have the nvptx bits in
there) and send middle-end and libgomp diffs against that?
As far as I remember, most of the changes from the branch are now approved,
they are just waiting for review of the LTO related changes in the
middle-end (please, correct me if I've missed something).

Jakub

[patch] OpenACC fortran front end

[Cesar Philippidis]

This patch adds support for OpenACC 2.0a, with some omissions, to the
fortran front end. It only contains the fortran changes from
gomp-4_0-branch, therefore the middle end and runtime changes are a
necessary prerequisite for this patch. I'll post a separate patch with
the fortran tests later. If anyone wants to test this patch, please use
gomp-4_0-branch instead. You don't need a CUDA accelerator to use
OpenACC, and some of the runtime tests will fail because that branch
doesn't include the nvptx backend.

Notable OpenACC omissions include support for the device_type clause and
the atomic directive. Hopefully we can get those in before 5.0 is released.

All of theses changes have been approved for gomp-4_0-branch. Is this
patch OK for mainline trunk (after the runtime and middle end go in)?

Ilmir, I know that you contributed most of OpenACC support to the
fortran front end. Am I missing any other authors in the ChangeLog?

Thanks,
Cesar

2014-11-06  Cesar Philippidis  ce...@codesourcery.com
	Thomas Schwinge  tho...@codesourcery.com
	Ilmir Usmanov  i.usma...@samsung.com

	gcc/fortran/
	* cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
	* dump-parse-tree.c
	(show_omp_node): Dump also OpenACC executable statements.
	(show_code_node): Call it.
	(show_namespace): Dump !$ACC DECLARE directive.
	* f95-lang.c (gfc_init_builtin_functions): Handle openacc builtins.
	* gfortran.h (gfc_statement): Add ST_OACC_PARALLEL_LOOP,
	ST_OACC_END_PARALLEL_LOOP, ST_OACC_PARALLEL, ST_OACC_END_PARALLEL,
	ST_OACC_KERNELS, ST_OACC_END_KERNELS, ST_OACC_DATA, ST_OACC_END_DATA,
	ST_OACC_HOST_DATA, ST_OACC_END_HOST_DATA, ST_OACC_LOOP,
	ST_OACC_END_LOOP, ST_OACC_DECLARE, ST_OACC_UPDATE, ST_OACC_WAIT,
	ST_OACC_CACHE, ST_OACC_KERNELS_LOOP, ST_OACC_END_KERNELS_LOOP,
	ST_OACC_ENTER_DATA, ST_OACC_EXIT_DATA, ST_OACC_ROUTINE.
	(gfc_expr_list): New struct.
	(gfc_omp_map_op): Add OMP_MAP_FORCE_ALLOC, OMP_MAP_FORCE_DEALLOC,
	OMP_MAP_FORCE_TO, OMP_MAP_FORCE_FROM, OMP_MAP_FORCE_TOFROM,
	OMP_MAP_FORCE_PRESENT.
	(enum): Add OMP_LIST_COPY, OMP_LIST_DATA_CLAUSE_FIRST,
	OMP_LIST_DEVICEPTR, OMP_LIST_DATA_CLAUSE_LAST, 
	OMP_LIST_DEVICE_RESIDENT, OMP_LIST_USE_DEVICE, OMP_LIST_CACHE,
	OMP_LIST_NUM, OMP_LIST_LAST = OMP_LIST_NUM.
	(struct gfc_omp_classes): Add async_expr, gang_expr, worker_expr,
	vector_expr, num_gangs_expr, num_workers_expr, vector_length_expr,
	wait_list, tile_list, async, gang, worker, vector, seq, independent,
	wait, par_auto, gang_static and union locus loc.
	(struct gfc_namespace): Add oacc_declare_clauses.
	(gfc_exec_op): Add EXEC_OACC_KERNELS_LOOP, EXEC_OACC_PARALLEL_LOOP,
	EXEC_OACC_PARALLEL, EXEC_OACC_KERNELS, EXEC_OACC_DATA,
	EXEC_OACC_HOST_DATA, EXEC_OACC_LOOP, EXEC_OACC_UPDATE, EXEC_OACC_WAIT,
	EXEC_OACC_CACHE, EXEC_OACC_ENTER_DATA, EXEC_OACC_EXIT_DATA.
	(gfc_option_t): Add gfc_flag_openacc.
	(gfc_free_expr_list): Declare.
	(gfc_resolve_oacc_directive): Declare.
	(gfc_resolve_oacc_declare): Declare.
	(gfc_resolve_oacc_parallel_loop_blocks): Declare.
	(gfc_resolve_oacc_blocks): Declare.
	* gfortran.texi: Add notes regarding OpenACC.
	* intrinsic.texi: Likewise.
	* invoke.texi: Likewise.
	* lang.opt (fopenacc): New option.
	* match.c (match_exit_cycle): Handle EXEC_OACC_LOOP and
	EXEC_OACC_PARALLEL_LOOP.
	* match.h (gfc_match_oacc_cache, gfc_match_oacc_wait,
	gfc_match_oacc_update, gfc_match_oacc_declare, gfc_match_oacc_loop,
	gfc_match_oacc_host_data, gfc_match_oacc_data, gfc_match_oacc_kernels,
	gfc_match_oacc_kernels_loop, gfc_match_oacc_parallel,
	gfc_match_oacc_parallel, gfc_match_oacc_parallel_loop,
	gfc_match_oacc_enter_data, gfc_match_oacc_exit_data,
	gfc_match_oacc_routine): Declare.
	* openmp.c (gfc_free_omp_clauses): Free various OpenACC exprs and
	lists.
	(gfc_free_expr_list): New function.
	(match_oacc_expr_list): New function.
	(match_oacc_clause_gang): New function.
	(OMP_CLAUSE_ASYNC, OMP_CLAUSE_NUM_GANGS, OMP_CLAUSE_NUM_WORKERS,
	OMP_CLAUSE_VECTOR_LENGTH, OMP_CLAUSE_COPY, OMP_CLAUSE_COPYOUT,
	OMP_CLAUSE_CREATE, OMP_CLAUSE_PRESENT, OMP_CLAUSE_PRESENT_OR_COPY,
	OMP_CLAUSE_PRESENT_OR_COPYIN, OMP_CLAUSE_PRESENT_OR_COPYOUT,
	OMP_CLAUSE_PRESENT_OR_CREATE, OMP_CLAUSE_DEVICEPTR,
	OMP_CLAUSE_GANG, OMP_CLAUSE_WORKER, OMP_CLAUSE_VECTOR,
	OMP_CLAUSE_SEQ, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_USE_DEVICE,
	OMP_CLAUSE_DEVICE_RESIDENT, OMP_CLAUSE_HOST_SELF,
	OMP_CLAUSE_OACC_DEVICE, OMP_CLAUSE_WAIT, OMP_CLAUSE_DELETE,
	OMP_CLAUSE_AUTO, OMP_CLAUSE_TILE): New defines.
	(gfc_match_omp_map_clause): New function.
	(gfc_match_omp_clauses): Handle OpenACC clauses.
	(OACC_PARALLEL_CLAUSES, define OACC_KERNELS_CLAUSES,
	OACC_DATA_CLAUSES, define OACC_LOOP_CLAUSES,
	OACC_PARALLEL_LOOP_CLAUSES, OACC_KERNELS_LOOP_CLAUSES,
	OACC_HOST_DATA_CLAUSES, OACC_DECLARE_CLAUSES, OACC_UPDATE_CLAUSES,
	OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES,
	OACC_WAIT_CLAUSES): New defines.
	(gfc_match_oacc_parallel_loop): New function.
	(gfc_match_oacc_parallel): New function.
	(gfc_match_oacc_kernels_loop): New function.