s quite a few fortran changes that
aren't present in trunk. Can you post those changes as a separate patch?
Thanks,
Cesar
num_gangs, num_workers and vector_length in gomp4. But
support for those clauses are already present in trunk. I'll post more
details with the patch later.
Cesar
2015-10-28 Cesar Philippidis
* gcc/c/c-parser.c (c_parser_oacc_simple_clause): New
function.
(c_parser_oacc_all_clauses): Us
a
similar patch if OpenACC adds new clauses of this form in the future.
I've applied this patch to gomp-4_0-branch.
Cesar
On 10/29/2015 07:08 AM, Cesar Philippidis wrote:
> In gomp-4_0-branch, we've tried to consolidate the parsing all of the
> clauses of the form
>
> foo (int-expression)
>
> into a single c*_parser_omp_positive_int_clause function. At the time,
> such clauses inclu
sion tested and bootstrapped on
x86_64-linux.
Cesar
2015-10-29 Cesar Philippidis
gcc/cp/
* parser.c (cp_parser_oacc_positive_int_clause): New function.
(cp_parser_oacc_clause_vector_length): Delete.
(cp_parser_omp_clause_num_gangs): Delete.
(cp_parser_omp_clause_num_w
On 10/30/2015 06:37 AM, Jakub Jelinek wrote:
> On Thu, Oct 29, 2015 at 04:02:11PM -0700, Cesar Philippidis wrote:
>> I noticed that num_gangs, num_workers and vector_length are parsed in
>> somewhat insistent ways in the c++ FE. Both vector_length and num_gangs
>> bail out whe
On 10/30/2015 07:47 AM, Jakub Jelinek wrote:
> On Thu, Oct 22, 2015 at 08:21:35AM -0700, Cesar Philippidis wrote:
>> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
>> index b2894cc..93adb7b 100644
>> --- a/gcc/fortran/gfortran.h
>> +++ b/gcc/fortran/gfort
t. That is kind of unrelated change.
Yeah, I was post the patch before I applied it anyway. Here's what I'm
testing now. I just into some fallout with Andrew MacLeod's header file
reduction patch when building offloading compilers. Seems like some
files are not including context.h
d compiler for openacc. It looks like cgraph.c needs to include
context.h and varpool.c needs context.h and omp-low.h. There's a couple
of ifdef ENABLE_OFFLOADING which may have gone undetected with your script.
I've bootstrapped the attached patch for an nvptx/x86_64-linux target.
I&#
On 10/30/2015 01:20 PM, Andrew MacLeod wrote:
> On 10/30/2015 02:09 PM, Andrew MacLeod wrote:
>> On 10/30/2015 01:56 PM, Cesar Philippidis wrote:
>>> On 10/23/2015 12:24 PM, Jeff Law wrote:
>>>> On 10/23/2015 10:53 AM, Andrew MacLeod wrote:
>>>>
>>&
On 10/30/2015 10:05 AM, Jakub Jelinek wrote:
> On Fri, Oct 30, 2015 at 07:42:39AM -0700, Cesar Philippidis wrote:
>>> Another thing is what Jason as C++ maintainer wants, it is nice to get rid
>>> of some code redundancies, on the other side the fact that there is one
built gcc with
--enable-bootstrap.
I've applied this patch to trunk, since it should have been included
with the original patch in the first place.
Cesar
2015-10-31 Cesar Philippidis
PR Bootstrap/68168
gcc/fortran/
* openmp.c (resolve_omp_clauses): Pass &n->where when callin
size-expr-list )
where size-expr is one of:
*
int-expr
That '*' symbol complicated the parsing a little, since it's no longer a
primary expression.
I've bootstrapped and regression tested this on x86_64. Is this ok for
trunk?
Cesar
2015-11-03 Cesar Phil
r of tests have either been updated or added.
Is this OK for trunk?
Cesar
2015-11-03 Cesar Philippidis
Thomas Schwinge
gcc/fortran/
* openmp.c (gfc_match_omp_clauses): Update support for the tile
and default clauses in OpenACC.
(gfc_match_oacc_update): Error when data clauses ar
On 11/04/2015 03:39 AM, Thomas Schwinge wrote:
> On Tue, 27 Oct 2015 11:36:10 -0700, Cesar Philippidis
> wrote:
>> * Proposed fortran cleanups and enhanced error reporting changes:
>> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02288.html
>
> ... has now been
a/gcc/testsuite/gfortran.dg/goacc/parallel-tree.f95
>> +++ b/gcc/testsuite/gfortran.dg/goacc/parallel-tree.f95
>> @@ -37,4 +37,3 @@ end program test
>>
>> ! { dg-final { scan-tree-dump-times "map\\(force_deviceptr:u\\)" 1
>> "original" } }
>> ! { dg-final { scan-tree-dump-times "private\\(v\\)" 1 "original" } }
>> -! { dg-final { scan-tree-dump-times "firstprivate\\(w\\)" 1 "original" } }
>
> Which of your source code changes does this change related to?
I think Nathan made this change because he found a bug in the test or
something. I just included this test because trunk should be capable to
handle it now.
Cesar
On 11/04/2015 02:24 AM, Jakub Jelinek wrote:
> On Tue, Nov 03, 2015 at 02:16:59PM -0800, Cesar Philippidis wrote:
>> +
>> + do
>> +{
>> + if (c_parser_next_token_is (parser, CPP_MULT))
>> +{
>> + c_parser_consume_token (parser);
On 11/04/2015 10:09 AM, Jason Merrill wrote:
> A single function is better, to avoid unnecessary code duplication.
Thanks. I've applied this patch to trunk.
Cesar
2015-11-04 Cesar Philippidis
gcc/cp/
* (cp_parser_oacc_single_int_clause): New
clauses. Is it
ok for trunk?
Cesar
2015-11-04 Cesar Philippidis
gcc/cp/
* pt.c (tsubst_omp_clauses): Add support for OMP_CLAUSE_{NUM_GANGS,
NUM_WORKERS,VECTOR_LENGTH,GANG,WORKER,VECTOR,ASYNC,WAIT,TILE,AUTO,
INDEPENDENT,SEQ}.
(tsubst_expr): Add support for OMP_CLAUSE_{KERNELS,PARALLE
it as-is since it works.
The c++ FE would have had problems with template support eventually
because it was doing type checking during scanning.
Cesar
2015-11-04 Cesar Philippidis
gcc/c/
* c-parser.c (c_parser_oacc_update): Update the error message for
missing clauses.
gcc/cp/
* par
On 11/05/2015 04:14 AM, Thomas Schwinge wrote:
> On Tue, 3 Nov 2015 14:16:59 -0800, Cesar Philippidis
> wrote:
>> This patch does the following to the c and c++ front ends:
>
>> * updates c_oacc_split_loop_clauses to filter out the loop clauses
>>from comb
On 11/04/2015 11:29 PM, Jakub Jelinek wrote:
> On Wed, Nov 04, 2015 at 08:58:32PM -0800, Cesar Philippidis wrote:
>> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
>> index e3f55a7..4424596 100644
>> --- a/gcc/cp/pt.c
>> +++ b/gcc/cp/pt.c
>> @@ -14395,6 +14395,15 @@ tsubs
On 11/05/2015 09:13 AM, Nathan Sidwell wrote:
> On 11/05/15 12:01, Thomas Schwinge wrote:
>
>> On Thu, 5 Nov 2015 06:47:58 -0800, Cesar Philippidis
>> wrote:
>>> On 11/05/2015 04:14 AM, Thomas Schwinge wrote:
>
>>> Sorry, I must have mis-phrased it. The sp
cation. I'm planning on adding a couple of more test cases once
acc reductions are working on trunk.
Cesar
2015-11-05 Cesar Philippidis
Thomas Schwinge
James Norris
gcc/
* gimplify.c (gimplify_scan_omp_clauses): Add support for
OMP_CLAUSE_TILE. Update handling
le to both to the kernels and loop
constructs for combined 'acc kernels loop'. The problem here is that
kernels don't support the reduction clause. I'll fix that next week.
Cesar
2015-11-06 Cesar Philippidis
gcc/c-family/
* c-omp.c (c_oacc_split_loop_clauses): Make TIL
s present on multiple clauses at %L",
+n->sym->name, &loc);
+ else
+ n->sym->mark = 1;
+ }
is unnecessary. I'm not sure if that you intended to check for other
lists or what.
I've applied this patch to gomp-4_0-
On 11/07/2015 04:30 AM, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 6 Nov 2015 15:31:23 -0800, Cesar Philippidis
> wrote:
>> I've applied this patch to gomp-4_0-branch which backports most of my
>> front end changes from trunk.
>
>> --- a/gcc/cp/pt.c
>&g
On 11/07/2015 03:45 AM, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 6 Nov 2015 15:31:23 -0800, Cesar Philippidis
> wrote:
>> I've applied this patch to gomp-4_0-branch which backports most of my
>> front end changes from trunk. Note that I found a regression while
>
++)
?
> + for (n = oc->clauses->lists[list]; n; n = n->next)
> + {
> + if (n->sym->mark)
> + gfc_error ("Symbol %qs present on multiple clauses at %L",
> + n->sym->name, &loc);
> + else
> + n->sym->mark = 1;
> + }
> +}
> +
> + for (oc = ns->oacc_declare; oc; oc = oc->next)
> +{
> + for (list = OMP_LIST_LINK; list <= OMP_LIST_LINK; list++)
?
> + for (n = oc->clauses->lists[list]; n; n = n->next)
> + n->sym->mark = 0;
> +}
> +}
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_*.
Cesar
ges.
>>
>> Otherwise, LGTM.
>
> This is the patch I've just committed. It includes c parser adjustments
> to detect the case of two function decls with a single type specifier.
> Cesar will be applying a patch for the C++ parser for the same case.
Here's th
On 11/09/2015 04:48 PM, Nathan Sidwell wrote:
> And these are the new tests. Cesar, c-c++-common/goacc/routine-5.c will
> need adjusting with your C++ parser patch. You'll see the two cases
> I've #if'd out.
I enabled those tests in trunk with the patch I posted here
<
On 11/10/2015 12:16 AM, Jakub Jelinek wrote:
> On Mon, Nov 09, 2015 at 09:28:47PM -0800, Cesar Philippidis wrote:
>> Here's the patch that Nathan was referring to. I ended up introducing a
>> boolean variable named first in the various functions which call
>> finalize_
parallel construct, the gimplifier
would introduce a pcopy clause for the reduction variable if it was not
associated with any data clause. Is that not the case anymore?
Cesar
On 11/11/2015 05:40 AM, Nathan Sidwell wrote:
> On 11/10/15 18:08, Cesar Philippidis wrote:
>> On 11/10/2015 12:35 PM, Nathan Sidwell wrote:
>>> I've committed this to gomp4. In preparing the reworked firstprivate
>>> patch changes for gomp4's gimplif
p.h:122:17: fatal error: sem.h: No such file or directory
#include "sem.h"
I'm still running the entire testsuite, but it doesn't introduce any new
regressions in libgomp.oacc-c. Is this OK for trunk, or am I missing
something?
Cesar
2015-11-17 Cesar Philippidis
libgomp/
*
On 11/17/2015 09:23 AM, Nathan Sidwell wrote:
> On 11/17/15 12:23, Nathan Sidwell wrote:
>> On 11/17/15 12:16, Cesar Philippidis wrote:
>>> This patch adds an empty priority_queues.c in libgomp for nvptx targets.
>>> Nvptx targets don't have sufficient support fo
s
affected though.
Is this patch ok for trunk?
Cesar
2015-11-17 Cesar Philippidis
gcc/cp/
* cp-gimplify.c (cp_fold_r): Add support for OACC_LOOP.
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 8fe9e13..99d0cfb 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
On 11/10/2015 12:16 AM, Jakub Jelinek wrote:
> On Mon, Nov 09, 2015 at 09:28:47PM -0800, Cesar Philippidis wrote:
>> Here's the patch that Nathan was referring to. I ended up introducing a
>> boolean variable named first in the various functions which call
>> finalize_
der if we should emit an error if
any acc constructs are used inside blocks? That's probably overly
pessimistic though.
Cesar
On 11/08/2015 07:45 AM, Tom de Vries wrote:
> On 07/11/15 12:45, Thomas Schwinge wrote:
>> Hi!
>>
>> On Fri, 6 Nov 2015 15:31:23 -0800, Cesar Philippidis
>> wrote:
>>> I've applied this patch to gomp-4_0-branch which backports most of my
>>>
have support for the bind and nohost clauses on trunk yet. Thomas posted
a patch right before stage1 closed. So if that patch gets accepted, I'll
create a follow up patch for routines in fortran.
This this OK for trunk?
Cesar
2015-11-19 Cesar Philippidis
gcc/
* tree-nested.c (convert
plied to gomp4.
As time permits, I'll add more test cases with invalid clause
combination for all of the constructs.
Cesar
2015-11-19 Cesar Philippidis
gcc/fortran/
* openmp.c (OACC_ROUTINE_CLAUSES): Remove OMP_CLAUSE_OACC_DEVICE
from the clause mask.
gcc/testsuite/
* gfortra
On 11/20/2015 02:18 AM, Jakub Jelinek wrote:
> On Thu, Nov 19, 2015 at 08:26:45AM -0800, Cesar Philippidis wrote:
>> (gfc_oacc_routine_name): New struct;
>
> Full stop instead of semicolon.
Fixed.
>> diff --git a/gcc/tree-nested.c b/gcc/tree-nested.c
>> in
t; + if (flag_openacc || (flag_openmp || flag_openmp_simd))
>
> I'd just write
> if (flag_openacc || flag_openmp || flag_openmp_simd)
> the ()s around are just misleading.
>
> Anyway, if the removal of "openmp_flag &&" is intentional, then
kernels and parallel constructs. Now, they are only
associated with the split acc loop.
Is this OK for trunk?
Cesar
2015-11-30 Cesar Philippidis
gcc/fortran/
* dump-parse-tree.c (show_omp_clauses): Handle optional num and static
arguments for the gang clause.
* gfortran.h (gfc_omp_clauses
o
exercise those changes.
This patch has been applied to gomp-4_0-branch.
Cesar
2015-11-30 Cesar Philippidis
gcc/
* tree-nested.c (convert_nonlocal_omp_clauses): Handle optional
arguments for OMP_CLAUSE_{GANG,WORKER,VECTOR}.
(convert_local_omp_clauses): Likewise
gcc/testsuite/
* gfortra
On 12/01/2015 06:40 AM, Thomas Schwinge wrote:
> I noticed while working on other test cases:
>
> On Wed, 18 Nov 2015 11:02:01 -0800, Cesar Philippidis
> wrote:
>> --- a/gcc/cp/parser.c
>> +++ b/gcc/cp/parser.c
>
>> @@ -1318,13 +1318,21 @@ cp_finalize_om
clauses in combined constructs with the acc loop. That code was
ifdef'ed out in gfc_filter_oacc_combined_clauses. I'll investigate this
later.
I've applied this patch to gomp-4_0-branch.
Cesar
2015-12-01 Cesar Philippidis
gcc/fortran/
* dump-parse-tree.c (show_omp_cla
c reductions
containing array variables.
Note that this solution is somewhat aggressive because we probably
should allow reductions on individual array elements. E.g.
!$acc loop reduction(+:var(1))
The c and c++ front ends also have that problem. Maybe I'll revisit this
later.
Is this ok f
On 12/02/2015 11:35 AM, Jakub Jelinek wrote:
> On Wed, Dec 02, 2015 at 11:16:10AM -0800, Cesar Philippidis wrote:
>>> --- gcc/testsuite/gfortran.dg/goacc/coarray_2.f90
>>> +++ gcc/testsuite/gfortran.dg/goacc/coarray_2.f90
>>> @@ -3,6 +3,7 @@
>>> !
>&
On 12/01/2015 06:49 AM, Cesar Philippidis wrote:
> On 12/01/2015 06:40 AM, Thomas Schwinge wrote:
>
>> I noticed while working on other test cases:
>>
>> On Wed, 18 Nov 2015 11:02:01 -0800, Cesar Philippidis
>> wrote:
>>> --- a/gcc/cp/parser.c
>&
" is missing: "not followed by single
> function"; that should be fixed up as well.)
>
>> Is this OK or do you prefer the "not followed by a single function" message?
>
> "not followed by a function declaration or definition&qu
Thomas,
that's something to keep in mind next time you do a trunk merge.
I've applied this patch to gomp-4_0-branch.
Cesar
2015-12-03 Cesar Philippidis
gcc/fortran/
* openmp.c (gfc_match_omp_clauses): Allow subarrays for acc reductions.
(resolve_omp_clauses): Error on any acc re
o gomp-4_0-branch. Some of the parallel tests
could probably go into trunk, but that'll wait for some other time.
Cesar
2015-12-04 Cesar Philippidis
libgomp/
* testsuite/libgomp.oacc-c-c++-common/{kernels-loop-4.c,
kernels-private-vars-local-worker-1.c,
kernels-private-vars-local-worke
bgomp/testsuite/libgomp.oacc-fortran/deviceptr-1.f90
> b/libgomp/testsuite/libgomp.oacc-fortran/deviceptr-1.f90
> new file mode 100644
> index 000..879cbf1
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/deviceptr-1.f90
> @@ -0,0 +1,197 @@
> +! { dg-do run }
> +
> +!! Test the deviceptr clause with various directives
> +!! and in combination with other directives where
> +!! the deviceptr variable is implied.
... here. And minor nit, but the other fortran tests only use a single
exclamation point for comments. This test should also use a single one
for consistency.
Cesar
gt; Fixed.
Where? I don't see a patch.
Since you're working on fortran, can you take a look at how
gfc_match_omp_clauses is handling OMP_CLAUSE_DEVICEPTR. It seems overly
confusing to me. Could it be done in a similar way as OMP_CLAUSE_COPYIN,
i.e., using gfc_match_omp_map_clause?
Cesar
On 08/01/2018 04:01 AM, Tom de Vries wrote:
> On 07/31/2018 05:12 PM, Cesar Philippidis wrote:
>> This is an old patch which removes the struct map from the nvptx plugin.
>> I believe at one point this was supposed to be used to manage async data
>> mappings, but in practice
On 08/01/2018 03:18 AM, Tom de Vries wrote:
> On 07/31/2018 04:58 PM, Cesar Philippidis wrote:
>> The attached patch teaches libgomp how to use the CUDA thread occupancy
>> calculator built into the CUDA driver. Despite both being based off the
>> CUDA thread occupancy spreads
lock, the driver
occupancy calculator ends up launching fewer gangs.
I don't have a firm position with this default behavior. Perhaps we
should just set
gang = grids
That's probably an improvement over what's there now.
Cesar
On 08/03/2018 08:22 AM, Tom de Vries wrote:
> On 08/01/2018 09:11 PM, Cesar Philippidis wrote:
>> On 08/01/2018 07:12 AM, Tom de Vries wrote:
>>
>>>>>> + gangs = grids * (blocks / warp_size);
>>>>>
>>>>> So, we launch wit
your changes yet. It still needs to be tested
against CUDA 5.5 using the systems/Nvidia's cuda.h. But I wanted to give
you an update.
Does this patch look OK, at least after testing competes? I removed the
tests for CUDA_ONE_CALL_MAYBE_NULL, because the newer CUDA API isn't
supported in the o
This patch removes a stale reference to trans-openacc.c in
gcc/fortran/trans-statement.h. I'll apply it to trunk as obvious shortly.
Cesar
>From a08fe168c3f3ca4d446915ad26027786cda58394 Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date: Tue, 14 Mar 2017 22:33:00 +
Subject
This patch updates how the OpenACC tile clause is handled in the Fortran
FE to match it's behavior in C/C++. Specifically, the tile clause now
errors on negative integer arguments, instead of emitting a warning.
Is this OK for trunk?
Thanks,
Cesar
>From af39a6d65cfb46397fa62c8852118900
to be transferred in via firstprivate
because that would use up a lot of memory on the accelerator.
Is this OK for trunk? I bootstrapped and regtested it for x86_64 with
nvptx offloading.
Thanks,
Cesar
>From b8fb83b36d0f96b12af9a1f5596f31b3c6b72ef0 Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date
OK for trunk? I bootstrapped and regression tested it for
x86_64 with nvptx offloading.
Thanks,
Cesar
>From 576b2a7d5574400f067ec309929b38b324d8c6f6 Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date: Fri, 27 Jan 2017 14:58:16 +
Subject: [PATCH] [OpenACC] Don't error on implicitly priva
using
GOMP_MAP_FORCE_DEVICEPTR.
Is this patch OK for trunk? It bootstrapped / regression tested cleanly
for x86_64 with nvptx offloading.
Thanks,
Cesar
>From b5cf37b795ce78c78f3f434ac6999f7094bd86aa Mon Sep 17 00:00:00 2001
From: Cesar Philippidis
Date: Mon, 7 May 2018 08:23:48 -0700
Subject: [PATCH] [OpenAC
On 08/07/2018 06:52 AM, Cesar Philippidis wrote:
> I attached an updated version of the CUDA driver patch, although I
> haven't rebased it against your changes yet. It still needs to be tested
> against CUDA 5.5 using the systems/Nvidia's cuda.h. But I wanted to give
> yo
On 08/08/2018 08:19 AM, Tom de Vries wrote:
> On Wed, Aug 08, 2018 at 07:09:16AM -0700, Cesar Philippidis wrote:
>> On 08/07/2018 06:52 AM, Cesar Philippidis wrote:
Thanks for review. This version should address all of the following
remarks. However, one thing to note ...
>> [
On 08/13/2018 05:04 AM, Tom de Vries wrote:
> On 08/10/2018 08:39 PM, Cesar Philippidis wrote:
>> is that I modified the default value for vectors as follows
>>
>> +int vectors = default_dim_p[GOMP_DIM_VECTOR]
>> + ? 0 : dims[GOMP_DIM_VECTOR];
&g
On 08/13/2018 08:08 AM, Tom de Vries wrote:
> On 08/13/2018 04:54 PM, Cesar Philippidis wrote:
>> Going
>> forward, how would you like to proceed with the nvptx BE vector length
>> changes.
>
> Do you have a branch available on github containing the patch series
>
. However, I see this regression on the host:
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-gwv-2.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -O2 execution test
There could be other regressions, but I only tested the new tests
introduced by the patch so far.
Cesar
On 08/13/2018 11:42 AM, Cesar Philippidis wrote:
> On 08/13/2018 09:21 AM, Julian Brown wrote:
>
>> diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-gwv-2.c
>> b/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-gwv-2.c
>> new file mode 100644
>> inde
> + if (OMP_CLAUSE_MAP_KIND (c) != GOMP_MAP_FORCE_PRESENT
> + && TREE_CODE (decl) == PARM_DECL
>&& GFC_ARRAY_TYPE_P (TREE_TYPE (decl))
>&& GFC_TYPE_ARRAY_AKIND (TREE_TYPE (decl)) == GFC_ARRAY_UNKNOWN
>&& GFC_TYPE_ARRAY_UBOUND (TREE_TYPE (decl),
This is specific to OpenACC, and needs to be guarded as such.
Cesar
On 08/28/2018 02:32 PM, Julian Brown wrote:
> On Tue, 28 Aug 2018 12:23:22 -0700
> Cesar Philippidis wrote:
>> This is specific to OpenACC, and needs to be guarded as such.
>
> Are you sure that condition can be true for OpenMP? I'd assumed not...
My bad, you're co
instructions for __atomic_fetch_{add,and,or,xor} for DI
integers. Without -misa, GCC would use an atomic CAS loop for them. As
an aside, this patch also enables PTX atom instructions for those
aforementioned functions for SI integers.
Is this patch OK for trunk?
Thanks,
Cesar
Basic -misa support for nvptx
On 09/01/2018 12:04 PM, Tom de Vries wrote:
> On 08/31/2018 04:14 PM, Cesar Philippidis wrote:
>> Is this patch OK for trunk?
>>
>
> Well, how did you test this (
> https://gcc.gnu.org/contribute.html#patches : "Bootstrapping and
> testing. State the host and ta
On 09/02/2018 07:57 AM, Cesar Philippidis wrote:
> On 09/01/2018 12:04 PM, Tom de Vries wrote:
>> On 08/31/2018 04:14 PM, Cesar Philippidis wrote:
>
>>> Is this patch OK for trunk?
>>>
>>
>> Well, how did you test this (
>> https://gcc.gnu.
. Now
gfc_trans_omp_clauses_1 can handle the allocatable scalar update directly.
I've applied this patch to gomp-4_0-branch.
Cesar
2017-06-08 Cesar Philippidis
gcc/fortran/
* gfortran.h gfc_omp_clauses: Add update_allocatable.
* trans-openmp.c (gfc_trans_omp_clauses_1): Set update_allocatable bit
I still need more time to review this, but ...
On 06/24/2017 12:54 AM, Chung-Lin Tang wrote:
> Hi Cesar, Thomas,
> This patch is the re-implementation of OpenACC async we talked about.
> The changes are rather large, so I am putting it here for a few days before
> actually committing
On 06/27/2017 03:56 AM, Chung-Lin Tang wrote:
> On 2017/6/27 6:45 AM, Cesar Philippidis wrote:
>>> (1) Instead of essentially implementing the entire OpenACC async support
>>> inside the plugin, we now use an opaque 'goacc_asyncqueue' implemented
>>&
his patch OK for trunk and gcc7?
Thanks,
Cesar
2017-06-29 Cesar Philippidis
PR fortran/77765
gcc/fortran/
* openmp.c (gfc_match_oacc_routine): Check if proc_name exist before
comparing the routine name against it.
gcc/testsuite/
* gfortran.dg/goacc/pr77765.f90: New test.
diff --g
runs too fast on the GPU so that
the copy'ed out data is correct, or the Nvidia's CUDA runtime blocks all
device->host data transfers until the GPU is no longer processing the
data. I suspect it's the former.
I've applied this patch to trunk and og7 as obvious.
Cesar
2017-1
spend too much
time on it if we decide to go with a different approach.
Any thoughts are welcome.
By the way, next we'll be working on increasing vector_length on nvptx
targets. In conjunction with that, we'll simplifying the OpenACC
execution model in the nvptx BE, along with adding
eneric address space when initializing variables using a label address.
Is this OK for trunk?
Thanks,
Cesar
2017-12-19 Cesar Philippidis
gcc/
* config/nvptx/nvptx.c (output_init_frag): Don't use generic address
spaces for function labels.
gcc/testsuite/
* gcc.target/nvptx/indirect_call.
On 12/19/2017 04:39 PM, Tom de Vries wrote:
> On 12/20/2017 12:25 AM, Cesar Philippidis wrote:
>> In CUDA 9, Nvidia removed support for treating the labels of functions
>> as generic address spaces as part of their PTX 6.0 changes. More
>> specifically,
>> <http:/
On 12/20/2017 03:15 PM, Tom de Vries wrote:
> On 12/20/2017 11:59 PM, Cesar Philippidis wrote:
>> On 12/19/2017 04:39 PM, Tom de Vries wrote:
>>> On 12/20/2017 12:25 AM, Cesar Philippidis wrote:
>>>> In CUDA 9, Nvidia removed support for treating the labels of fun
On 12/18/2017 02:58 PM, Cesar Philippidis wrote:
> Jakub,
>
> I'd like your thoughts on the following problem.
>
> One of the offloading bottlenecks with GPU acceleration in OpenACC is
> the nontrivial offloaded function invocation overhead. At present, GCC
> gener
ns to the fortran FE.
Is this patch OK for trunk? I tested with x86_64-linux with nvptx
acceleration.
Thanks,
Cesar
2018-05-25 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
gcc/c-family/
* c-pragma.h (enum pragma_omp_clause): Add
PRAGMA_OA
. It this OK for trunk?
Thanks,
Cesar
2018-05-31 Chung-Lin Tang
Cesar Philippidis
PR middle-end/85879
gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Add 'remove = true'
when emitting error on private/firstprivate reductions.
* omp-low.c (lower_omp_target): Avoid refe
, this may have to
be revisited.
I tested this patch on x86_64 with nvptx offloading. Is it OK for trunk
and the stable branches?
Thanks,
Cesar
2018-06-05 Cesar Philippidis
PR fortran/85701
gcc/fortran/
* openmp.c (gfc_resolve_oacc_declare): Error on functions and
subroutine data clause
ch to trunk as obvious.
Cesar
2018-06-13 Cesar Philippidis
PR fortran/85702
gcc/fortran/
* openmp.c (gfc_match_oacc_wait): Use %C to report error location.
gcc/testsuite/
* gfortran.dg/goacc/pr85702.f90: New test.
>From 07022efa1ba4a58fa12c3f8a3b911fba32a5df1b Mon Sep 17 00:00:00 2
ement decoders, and
therein lies the problems. The fix is to reset gfc_matching_function
early in those functions.
Is this OK for trunk and GCC 8?
Thanks,
Cesar
2018-06-13 Cesar Philippidis
PR fortran/85703
gcc/fortran/
* parse.c (decode_oacc_directive): Set gfc_matching_function
to
Ping.
To make this patch easier to review, I'll split it into individual
patches for each major component in follow up emails.
Cesar
On 05/25/2018 01:01 PM, Cesar Philippidis wrote:
> This patch updates GCC's to support OpenACC 2.5's data clause semantics.
> In OpenACC
This patch implements the OpenACC 2.5 data clause semantics in the C++ FE.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
gcc/cp/
* parser.c (cp_parser_omp_clause_name): Add support for finalize
and if_present. Make present_or_{copy
This patch implements the OpenACC 2.5 data clause semantics in the C FE.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
gcc/c/
* c-parser.c (c_parser_omp_clause_name): Add support for finalize
and if_present. Make present_or_{copy,copyin
This patch implements the OpenACC 2.5 data clause semantics in the
Fortran FE.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
gcc/fortran/
* gfortran.h (gfc_omp_clauses): Add unsigned if_present, finalize
bitfields.
* openmp.c (enum
This patch implements the OpenACC 2.5 data clause semantics in the
middle end.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
gcc/c-family/
* c-pragma.h (enum pragma_omp_clause): Add
PRAGMA_OACC_CLAUSE_{FINALIZE,IF_PRESENT}. Remove
This patch implements the OpenACC 2.5 data clause semantics in libgomp.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
libgomp/
* libgomp.h (struct splay_tree_key_s): Add dynamic_refcount member.
(gomp_acc_remove_pointer): Update
This patch updates the existing OpenACC compiler tests with the new
OpenACC 2.5 data clause semantics.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
gcc/testsuite/
* c-c++-common/goacc/declare-1.c: Update test case to utilize OpenACC
2.5
This patch updates the existing OpenACC libgomp runtime tests with the
new OpenACC 2.5 data clause semantics.
Is it OK for trunk?
Cesar
2018-06-19 Chung-Lin Tang
Thomas Schwinge
Cesar Philippidis
libgomp/
* testsuite/libgomp.oacc-c-c++-common/data-already-1.c: Update test
case
101 - 200 of 637 matches
Mail list logo
