[openacc] tile, independent, default, private and firstprivate support in c/++

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

[openacc] acc loop updates in fortran

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

Re: [gomp4] fortran cleanups and c/c++ loop parsing backport

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

Re: [openacc] acc loop updates in fortran

On 11/04/2015 09:15 AM, Thomas Schwinge wrote: >> --- a/gcc/fortran/trans-openmp.c >> +++ b/gcc/fortran/trans-openmp.c > >> @@ -3449,16 +3478,28 @@ gfc_trans_oacc_combined_directive (gfc_code *code) >>sizeof (construct_clauses)); >>loop_clauses.collapse = construct_clauses.col

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

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);

Re: [OpenACC] num_gangs, num_workers and vector_length in c++

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

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

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

[gomp4] assorted trunk backports

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

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

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

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

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

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

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

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

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

[gomp4] backport trunk FE changes

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

[gomp4] revert fortran declare changes

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-

Re: [gomp4] backport trunk FE changes

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

Re: Combined constructs' clause splitting

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 >

Re: Re: OpenACC declare directive updates

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

Re: [1/2] OpenACC routine support

ng 'first', which is set to true if the current declarator is the first in a sequence of declarators, I was able to defer setting parser->oacc_routine to NULL. Nathan already approved this patch, so I've applied it to trunk. Cesar 2015-11-09 Cesar Philippidis gcc/cp/ * pa

Re: [1/2] OpenACC routine support

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

Re: [1/2] OpenACC routine support

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_

Re: [gomp4] Fix some broken tests

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 gimplify.c I discovered these testcases were > passing by accident, and lacked a data clause. It used to be if a reduction was on a parallel construct,

Re: [gomp4] Fix some broken tests

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

nvptx priority queues nonsupport in libgomp

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/ *

Re: nvptx priority queues nonsupport in 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

teach delay folding in c++ about OACC_LOOPs

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

Re: [1/2] OpenACC routine support

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_

Re: Re: OpenACC declare directive updates

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

Re: Combined constructs' clause splitting

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 >>>

update acc routines in fortran

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

[gomp4] teach fortran to reject the device clause in acc routines

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

Re: update acc routines in fortran

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

Re: [PR fortran/63858] Fix mix of OpenACC and OpenMP sentinels in continuations

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

[openacc] fortran loop clauses and splitting

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

[gomp4] fortran routine backports

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

Re: [1/2] OpenACC routine support

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

[gomp4] backport fortran gang parsing updates

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

Re: [OpenACC 0/7] host_data construct

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

Re: [OpenACC 0/7] host_data construct

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 @@ >>> ! >&

Re: [1/2] OpenACC routine support

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 >&

Re: [1/2] OpenACC routine support

" 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

[gomp4] backport fortran array reduction changes

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

[gomp4] more runtime test coverage

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

Re: [gomp4] Fix Fortran deviceptr

On 12/06/2015 06:52 AM, James Norris wrote: > This patch fixes a some runtime issues when dealing with > the deviceptr clause in Fortran. There were some corner > cases that were not being dealt with correctly, and the > patch resolves these. Also a new set of test cases has > been added. Which c

Re: [gomp4] Fix Fortran deviceptr

On 12/08/2015 08:22 AM, James Norris wrote: >> 2. It appears that deviceptr code in GOACC_parallel_keyed is mostly >> identical to GOACC_data_start. Can you put that duplicate code into >> a function? That would be easier to maintain in the long run. >> > > Fixed. Where? I don't see

Re: [PATCH,nvptx] Remove use of 'struct map' from plugin (nvptx)

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

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

On 08/01/2018 07:12 AM, Tom de Vries wrote: +gangs = grids * (blocks / warp_size); >>> >>> So, we launch with gangs == grids * workers ? Is that intentional? >> >> Yes. At least that's what I've been using in og8. Setting num_gangs = >> grids alone caused significant slow downs. >> >

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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

[PATCH][OpenACC] cleanup trans-stmt.h

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

[PATCH][OpenACC] update gfortran's tile clause error handling

2fb3d705 Mon Sep 17 00:00:00 2001 From: Cesar Philippidis Date: Mon, 3 Oct 2016 13:58:59 + Subject: [PATCH] [OpenACC] update gfortran's tile clause error handling 2018-XX-YY Cesar Philippidis gcc/fortran/ * openmp.c (resolve_positive_int_expr): Promote the warning to an error.

[PATCH][OpenACC] Add support for firstprivate Fortran allocatable scalars

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

[PATCH][OpenACC] Don't error on implicitly private induction variables in gfortran

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

[PATCH][OpenACC] Update deviceptr handling during gimplification

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

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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 ... >> [

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

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 >

Re: [PATCH, OpenACC] Add support for gang local storage allocation in shared memory

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 > index 000..2fa708a > --- /dev/null > +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/loop

Re: [PATCH, OpenACC] Add support for gang local storage allocation in shared memory

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

Re: [PATCH, OpenACC] (2/2) Fix implicit mapping for array slices on lexically-enclosing data constructs (PR70828)

On 08/28/2018 12:19 PM, Julian Brown wrote: > diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c > index f038f4c..86be407 100644 > --- a/gcc/fortran/trans-openmp.c > +++ b/gcc/fortran/trans-openmp.c > @@ -1045,9 +1045,13 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p) > >

Re: [PATCH, OpenACC] (2/2) Fix implicit mapping for array slices on lexically-enclosing data constructs (PR70828)

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

[patch,nvptx] Basic -misa support for nvptx

2018-XX-YY Cesar Philippidis Bernd Schmidt gcc/ * config/nvptx/nvptx-opts.h: New file. * config/nvptx/nvptx.c (nvptx_file_start): Print the correct .target. * config/nvptx/nvptx.h: Include "nvptx-opts.h". (ASM_SPEC): Define. (TARGET_SM35): New macro. * config/nvpt

Re: [patch,nvptx] 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

Re: [patch,nvptx] Basic -misa support for nvptx

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.

[gomp4] Properly handle allocatable scalars in acc update.

. 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

Re: [gomp4] OpenACC async re-work

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 them to gomp-

Re: [gomp4] OpenACC async re-work

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 >>&

[PATCH] Fix PR77765

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

[patch] Fix bug in an OpenACC async test case

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

[PATCH,WIP] Use functional parameters for data mappings in OpenACC child functions

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

[PATCH,PTX] Add support for CUDA 9

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.

Re: [PATCH,PTX] Add support for CUDA 9

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:/

Re: [PATCH,PTX] Add support for CUDA 9

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

Re: [PATCH,WIP] Use functional parameters for data mappings in OpenACC child functions

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

[OpenACC] Update OpenACC data clause semantics to the 2.5 behavior

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

[PATCH] fix checking error with OpenACC reference types variables (PR85879)

. 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

[PATCH] Reject function and subroutine arguments in OpenACC declare data clauses (PR85701)

, 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

[PATCH] update error reporting for OpenACC wait (PR85702)

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

[PATCH] handle OpenMP/OpenACC regions inside Fortran character functions (PR85703)

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - C++

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - C

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - Fortran

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - middle end

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - compiler tests

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime tests

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

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

On 06/20/2018 09:45 AM, Jakub Jelinek wrote: > On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote: >> >From 53ee03231c5e6e4747b4ef01335079a2d4a98480 Mon Sep 17 00:00:00 2001 >> From: Cesar Philippidis >> Date: Tue, 19 Jun 2018 09:33:04 -0700 >> Subjec

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime

On 06/20/2018 10:03 AM, Jakub Jelinek wrote: > On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote: >> If it means anything, we have a significant async change that removes >> the async_refcount field in that struct. > > Wasn't async_refcount removed 2 y

[patch] adjust default nvptx launch geometry for OpenACC offloaded regions

is patch OK for trunk? Thanks, Cesar 2018-06-20 Cesar Philippidis gcc/ * config/nvptx/nvptx.c (PTX_GANG_DEFAULT): Delete define. (PTX_DEFAULT_RUNTIME_DIM): New define. (nvptx_goacc_validate_dims): Use it to allow the runtime to dynamically allocate

Re: [patch] adjust default nvptx launch geometry for OpenACC offloaded regions

On 06/20/2018 03:15 PM, Tom de Vries wrote: > On 06/20/2018 11:59 PM, Cesar Philippidis wrote: >> Now it follows the formula contained in >> the "CUDA Occupancy Calculator" spreadsheet that's distributed with CUDA. > > Any reason we're not using the cuda

Re: [patch] adjust default nvptx launch geometry for OpenACC offloaded regions

Ping. Ceasr On 06/20/2018 02:59 PM, Cesar Philippidis wrote: > At present, the nvptx libgomp plugin does not take into account the > amount of shared resources on GPUs (mostly shared-memory are register > usage) when selecting the default num_gangs and num_workers. In certain > si

[patch] Update support for Fortran arrays in OpenACC

e reported line number in fortran combined OpenACC directives Is this patch OK for trunk? It bootstrapped / regression tested cleanly for x86_64 with nvptx offloading. Thanks, Cesar 2018-06-29 Cesar Philippidis gcc/fortran/ * trans-array.c (gfc_trans_array_bounds): Add an INIT_VLA ar

Re: [patch] Update support for Fortran arrays in OpenACC

On 06/29/2018 10:49 AM, Jakub Jelinek wrote: > On Fri, Jun 29, 2018 at 10:33:56AM -0700, Cesar Philippidis wrote: >> @@ -1044,21 +1046,6 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p) >> return; >> >>tree decl = OMP_CLAUSE_DECL (c); >> - >

[patch] various OpenACC reduction enhancements

The following patch set includes various OpenACC reduction enhancements present in og8. These include the following individual og8 commits: * (4469fc4) [Fortran] Permit reductions in gfc_omp_clause_copy_ctor * (704f1a2) [nxptx, OpenACC] vector reductions * (8a35c89) [OpenACC] Fix a reduction

Re: [patch] various OpenACC reduction enhancements - ME and nvptx changes

The attached patch includes the nvptx and GCC ME reductions enhancements. Is this patch OK for trunk? It bootstrapped / regression tested cleanly for x86_64 with nvptx offloading. Thanks, Cesar 2018-06-29 Cesar Philippidis Nathan Sidwell gcc/ * config/nvptx/nvptx.c

Re: [patch] various OpenACC reduction enhancements - FE changes

Attaches are the FE changes for the OpenACC reduction enhancements. It depends on the ME patch. Is this patch OK for trunk? It bootstrapped / regression tested cleanly for x86_64 with nvptx offloading. Thanks, Cesar 2018-06-29 Cesar Philippidis Nathan Sidwell gcc/c/ * c-parser.c

Re: [patch] various OpenACC reduction enhancements - test cases

Attached are the updated reductions tests cases. Again, these have been bootstrapped and regression tested cleanly for x86_64 with nvptx offloading. Is it OK for trunk? Thanks, Cesar 2018-06-29 Cesar Philippidis Nathan Sidwell gcc/testsuite/ * c-c++-common/goacc/orphan-reductions-1.c

[patch] Add OpenACC Fortran support for deviceptr and variable in common blocks

is patch OK for trunk? It bootstrapped / regression tested cleanly for x86_64 with nvptx offloading. Thanks, Cesar 2018-06-29 Cesar Philippidis James Norris gcc/fortran/ * openmp.c (gfc_match_omp_map_clause): Re-write handling of the deviceptr clause. Add new common_blocks a

<    1   2   3   4   5   6   7   >