ACC_declare'
Given that we 'continue' for 'GOMP_MAP_POINTER', we cannot possibly encounter
it afterwards.
Small fix-up for r230275 (commit 6e232ba4246ca324a663ec5ddf0ba4db5cf3fbad)
"[OpenACC] declare directive".
libgomp/
* oacc-parallel.c (GOACC_declare): Clea
nk' attributes for Fortran OpenACC 'declare'd
variables", see attached.
Grüße
Thomas
From b7194d24d942998da2ab8f6f5dc080e3fff81972 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Tue, 18 Jun 2019 22:15:43 +
Subject: [PATCH] [PR85221] Set 'omp declare target',
Hi!
On Mon, 23 Nov 2015 13:37:20 +0100, I wrote:
> Hi Jim!
>
> A few things I noticed when working on merging your trunk r230275 into
> gomp-4_0-branch. Please fix these (on trunk).
> | --- include/gomp-constants.h
> | +++ include/gomp-constants.h
> | @@ -72,6 +72,11 @@ enum gomp_map_kind
> |
te/c-c++-common/goacc/declare-1.c
@@ -1,5 +1,5 @@
-/* Test valid uses of declare directive. */
-/* { dg-do compile } */
+/* Test valid use of the OpenACC 'declare' directive. */
+
int v0;
#pragma acc declare create(v0)
@@ -25,6 +25,7 @@ int v9;
int v10;
#pragma acc declare present_o
Hi!
On Thu, 19 Nov 2015 10:22:16 -0600, James Norris
wrote:
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
Don't you need to handle OMP_LIST_LINK in
gcc/fortran/dump-parse-tree.c:show_omp_clauses; OMP_LIST_DEVICE_RESIDENT
is being handled there (but maps to the wron
Hi!
On Mon, 23 Nov 2015 13:37:20 +0100, I wrote:
> A few things I noticed when working on merging your trunk r230275 into
> gomp-4_0-branch. [...]
I have now committed the merge of your trunk r230275 into
gomp-4_0-branch, in r230787. This was non-trivial: the implementation of
OpenACC declare o
plify.c
| +/* Return true if global var DECL is device resident. */
| +
| +static bool
| +device_resident_p (tree decl)
I suggest to improve that function's very generic name, and its
descriptive comment. Without more context, the casual reader will not
understand what "device residen
On Thu, Nov 19, 2015 at 10:22:16AM -0600, James Norris wrote:
> 2015-XX-XX James Norris
> Cesar Philippidis
>
> gcc/fortran/
> * dump-parse-tree.c (show_namespace): Handle declares.
> * gfortran.h (struct symbol_attribute): New fields.
> (enum gfc_omp_map_map
Jakub,
Here's the updated version of the Fortran changes. More test
cases have been added as well as the issues that Cesar
pointed on in error checking have been addressed (Thanks).
I've also addressed the issue, described below, in dealing
with declare directives when found within a BLOCK constr
On 11/08/2015 08:53 PM, James Norris wrote:
> The attached patch and ChangeLog reflect the updates from your
> review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00714.html
> and Cesar's review:
> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00885.html.
>
> With the changes made in this patch
Jakub
On 11/12/2015 03:09 AM, Jakub Jelinek wrote:
On Wed, Nov 11, 2015 at 07:07:58PM -0600, James Norris wrote:
+ oacc_declare_returns->remove (t);
+
+ if (oacc_declare_returns->elements () == 0)
+ {
+ delete oacc_declare_re
On Wed, Nov 11, 2015 at 07:07:58PM -0600, James Norris wrote:
> + oacc_declare_returns->remove (t);
> +
> + if (oacc_declare_returns->elements () == 0)
> + {
> + delete oacc_declare_returns;
> + oacc_declare_returns = N
Jakub,
The attached patch and ChangeLog reflect the updates from your
review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01317.html.
Highlights
The following issue was handled by Dominique d'Humières
in: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01375.html
On 11/11/2015 02:32 AM, Ja
> > "Would be really nice" means that you're asking us to work on and resolve
> > PR68271 before installing this patch?
>
> Dominique has committed a quick hack for this, so it is not urgent, but
> would be nice to get it resolved. If somebody from Mentor gets to that,
> perfect, otherwise I (or s
On Wed, Nov 11, 2015 at 11:08:21AM +0100, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 11 Nov 2015 09:32:33 +0100, Jakub Jelinek wrote:
> > On Mon, Nov 09, 2015 at 05:11:44PM -0600, James Norris wrote:
> > > diff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
> > > index 953c4e3..c6a2981 1
Hi!
On Wed, 11 Nov 2015 09:32:33 +0100, Jakub Jelinek wrote:
> On Mon, Nov 09, 2015 at 05:11:44PM -0600, James Norris wrote:
> > diff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
> > index 953c4e3..c6a2981 100644
> > --- a/gcc/c-family/c-pragma.h
> > +++ b/gcc/c-family/c-pragma.h
> >
On Mon, Nov 09, 2015 at 05:11:44PM -0600, James Norris wrote:
> diff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
> index 953c4e3..c6a2981 100644
> --- a/gcc/c-family/c-pragma.h
> +++ b/gcc/c-family/c-pragma.h
> @@ -30,6 +30,7 @@ enum pragma_kind {
>PRAGMA_OACC_ATOMIC,
>PRAGMA_
Jakub,
The attached patch and ChangeLog reflects the updates from your
review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01002.html
All of the issues you pointed out have been addressed. I've also
added a test that uses C++ templates. A bug was also fixed in the
parsers which dealt with det
Jakub,
On 11/09/2015 10:21 AM, Jakub Jelinek wrote:
On Mon, Nov 09, 2015 at 10:01:32AM -0600, James Norris wrote:
+ if (lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
Here you only look up "omp declare target", not "omp declare target link".
So, what happens if you mix t
On Mon, Nov 09, 2015 at 10:01:32AM -0600, James Norris wrote:
> + if (lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
Here you only look up "omp declare target", not "omp declare target link".
So, what happens if you mix that (once in some copy clause, once in link),
or menti
Jakub,
This is an update of the patch from:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00893.html.
There was an unused variable in c/c-parser.c that was
removed.
I've included the ChangeLog as a convenience, but nothing
was changed in the file.
Thanks!
Jim
2015-XX-XX James Norris
Cesar,
I only noticed these because I thought I fixed them in the patch you
asked me to revert from gomp-4_0-branch. At the very least, please try
to be consistent on iterating OMP_LIST_*.
Thank you for noticing!
Jakub,
The attached patch and ChangeLog reflect the updates from your
review: ht
On 11/08/2015 07:29 AM, James Norris wrote:
> The attached patch and ChangeLog reflect the updates from your
> review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00714.html.
> All of the issues pointed out, have been address.
>
> With the changes made in this patch I think I'm handling the
> s
Jakub,
The attached patch and ChangeLog reflect the updates from your
review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00703.html.
The most significant change was the one that you suggestion:
On 11/06/2015 02:28 PM, Jakub Jelinek wrote:
> Perhaps what would work is stick the exit clauses y
Jakub,
The attached patch and ChangeLog reflect the updates from your
review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00714.html.
All of the issues pointed out, have been address.
With the changes made in this patch I think I'm handling the
situation that you pointed out here correctly:
O
On 11/06/2015 02:28 PM, Jakub Jelinek wrote:
On Fri, Nov 06, 2015 at 02:18:11PM -0600, James Norris wrote:
On 11/06/2015 01:22 PM, Jakub Jelinek wrote:
On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote:
What exactly do you want to achieve? Why do you record it
in gimplify_omp_ctx,
On Fri, Nov 06, 2015 at 02:18:11PM -0600, James Norris wrote:
> On 11/06/2015 01:22 PM, Jakub Jelinek wrote:
> >On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote:
> >>What exactly do you want to achieve? Why do you record it
> >>in gimplify_omp_ctx, but then only look at it in gimplify
Jakub,
On 11/06/2015 01:49 PM, Jakub Jelinek wrote:
On Fri, Nov 06, 2015 at 01:45:09PM -0600, James Norris wrote:
Okay, I'll fix this.
After fixing, OK to commit?
Thank you for taking the time for the review.
Well, isn't this patch really dependent on the other one?
Yes. Should I combine t
Jakub,
On 11/06/2015 01:22 PM, Jakub Jelinek wrote:
On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote:
What exactly do you want to achieve? Why do you record it
in gimplify_omp_ctx, but then only look at it in gimplify_body?
The way you abuse gimplify_omp_ctx for that is just too u
Jakub,
On 11/06/2015 01:03 PM, Jakub Jelinek wrote:
On Fri, Nov 06, 2015 at 10:08:26AM -0600, James Norris wrote:
2015-10-27 James Norris
Joseph Myers
gcc/
* c-family/c-pragma.c (oacc_pragmas): Add entry for declare directive.
* c-family/c-pragma.h (enu
On Fri, Nov 06, 2015 at 01:45:09PM -0600, James Norris wrote:
> Okay, I'll fix this.
>
> After fixing, OK to commit?
>
> Thank you for taking the time for the review.
Well, isn't this patch really dependent on the other one?
Also, wonder about BLOCK stmt in Fortran, that can give you variables
Jakub,
On 11/06/2015 01:31 PM, Jakub Jelinek wrote:
On Wed, Nov 04, 2015 at 06:32:00AM -0600, James Norris wrote:
+/* Node in the linked list used for storing !$oacc declare constructs. */
+
+typedef struct gfc_oacc_declare
+{
+ struct gfc_oacc_declare *next;
+ bool module_var;
+ gfc_omp_c
On Wed, Nov 04, 2015 at 06:32:00AM -0600, James Norris wrote:
> +/* Node in the linked list used for storing !$oacc declare constructs. */
> +
> +typedef struct gfc_oacc_declare
> +{
> + struct gfc_oacc_declare *next;
> + bool module_var;
> + gfc_omp_clauses *clauses;
> + gfc_omp_clauses *retu
On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote:
> What exactly do you want to achieve? Why do you record it
> in gimplify_omp_ctx, but then only look at it in gimplify_body?
> The way you abuse gimplify_omp_ctx for that is just too ugly.
> All the gimplification code expects that wh
On Fri, Nov 06, 2015 at 10:08:26AM -0600, James Norris wrote:
> 2015-10-27 James Norris
> Joseph Myers
>
> gcc/
> * c-family/c-pragma.c (oacc_pragmas): Add entry for declare directive.
> * c-family/c-pragma.h (enum pragma_kind): Add PRAGMA_OACC_DECLARE.
c-family/
On 11/06/2015 10:08 AM, James Norris wrote:
Thomas,
I've added the issues that you pointed out. Attached
is the updated patch and ChangeLog.
Thanks for taking the time for your review!
Errr, make that 'addressed the issues that you pointed out."
Opps,
Jim
e updated patch ready for
you when you walk in on your Monday.
Thank you,
Jim
On 11/04/2015 10:49 AM, Thomas Schwinge wrote:
Hi Jim!
On Tue, 3 Nov 2015 10:31:32 -0600, James Norris
wrote:
On 10/27/2015 03:18 PM, James Norris wrote:
This patch adds the processing of OpenACC declare
Jakub,
Ping.
Do you need more information before you can review this patch?
Thanks!
Jim
On 10/27/2015 03:18 PM, James Norris wrote:
Hi!
This patch adds the processing of OpenACC declare directive in C
and C++. (Note: Support in Fortran is already in trunk.)
Commentary on the
Jakub,
Ping
Do you need more information before you can review this patch?
Thanks!
Jim
On 11/04/2015 06:32 AM, James Norris wrote:
This patch updates the processing of OpenACC declare directive for
Fortran in the following areas:
1) module support
2
Hi Thomas,
On 11/04/2015 10:49 AM, Thomas Schwinge wrote:
Hi Jim!
On Tue, 3 Nov 2015 10:31:32 -0600, James Norris
wrote:
On 10/27/2015 03:18 PM, James Norris wrote:
This patch adds the processing of OpenACC declare directive in C
and C++. (Note: Support in Fortran is already in
Hi Jim!
On Tue, 3 Nov 2015 10:31:32 -0600, James Norris
wrote:
> On 10/27/2015 03:18 PM, James Norris wrote:
> > This patch adds the processing of OpenACC declare directive in C
> > and C++. (Note: Support in Fortran is already in trunk.)
..., and a patch adjusting som
This patch updates the processing of OpenACC declare directive for
Fortran in the following areas:
1) module support
2) device_resident and link clauses
3) clause checking
4) directive generation
Commentary on the changes is included as an attachment
On 10/27/2015 03:18 PM, James Norris wrote:
Hi!
This patch adds the processing of OpenACC declare directive in C
and C++. (Note: Support in Fortran is already in trunk.)
Commentary on the changes is included as an attachment (NOTES).
All of the code is in the gomp-4_0
This patch updates the processing of OpenACC declare directive for
Fortran in the following areas:
1) module support
2) device_resident and link clauses
3) clause checking
4) directive generation
Commentary on the changes is included as an attachment
Cesar,
On 10/28/2015 11:32 AM, Cesar Philippidis wrote:
On 10/27/2015 01:18 PM, James Norris wrote:
> This patch adds the processing of OpenACC declare directive in C
> and C++. (Note: Support in Fortran is already in trunk.)
> Commentary on the changes is inclu
On 10/27/2015 01:18 PM, James Norris wrote:
> This patch adds the processing of OpenACC declare directive in C
> and C++. (Note: Support in Fortran is already in trunk.)
> Commentary on the changes is included as an attachment (NOTES).
A quick diff of gomp4 and trunk reveal
Hi!
This patch adds the processing of OpenACC declare directive in C
and C++. (Note: Support in Fortran is already in trunk.)
Commentary on the changes is included as an attachment (NOTES).
All of the code is in the gomp-4_0-branch.
Regtested on x86_64-linux.
Thanks
47 matches
Mail list logo