Add 'libgomp.oacc-fortran/declare-allocatable-1.f90' (was: [gomp4] add support for fortran allocate support with declare create)

Hi! On 2017-04-05T08:23:58-0700, Cesar Philippidis wrote: > This patch implements the OpenACC 2.5 behavior of fortran allocate on > variables marked with declare create as defined in Section 2.13.2 in the > OpenACC spec. That functionality is still missing in GCC master branch, however a test ca

Re: [gomp4] Make OpenACC orphan gang reductions errors

Hi! On 2017-05-01T18:27:59-0700, Cesar Philippidis wrote: > gcc/c/ > * c-typeck.c (c_finish_omp_clauses): Emit an error on orphan OpenACC > gang reductions. > > gcc/cp/ > * semantics.c (finish_omp_clauses): Emit an error on orphan OpenACC > gang reductions. > >

Re: [gomp4] Make OpenACC orphan gang reductions errors

Hi! On 2017-05-01T18:27:59-0700, Cesar Philippidis wrote: > --- a/gcc/fortran/openmp.c > +++ b/gcc/fortran/openmp.c > @@ -6090,6 +6090,18 @@ resolve_oacc_loop_blocks (gfc_code *code) > + if (code->op == EXEC_OACC_LOOP > + && code->ext.omp_clauses->lists[OMP_LIST_REDUCTION] > + && code

Re: [gomp4] Make OpenACC orphan gang reductions errors

Hi! On 2017-05-01T18:27:59-0700, Cesar Philippidis wrote: > This patch promotes all OpenACC gang reductions on orphan loops as > errors. Accord to the spec, orphan loops are those which are not > lexically nested inside an OpenACC parallel or kernels regions. I.e., > acc loops inside acc routines

Re: [gomp4] Update error messages for c and c++ reductions

Hi! On 2017-04-26T13:08:11-0700, Cesar Philippidis wrote: > This patches updates the c and c++ FEs to report consistent error > messages for invalid reductions involving array elements, struct > members, and class members. Most of those variables were already > rejected by the generic OpenMP code

[committed] [PR85221] Set 'omp declare target', 'omp declare target link' attributes for Fortran OpenACC 'declare'd variables (was: [gomp4] Re: OpenACC declare directive updates)

Hi! On Fri, 27 Nov 2015 12:37:23 +0100, I wrote: > On Thu, 19 Nov 2015 10:22:16 -0600, James Norris > wrote: > > [...] > Merging your trunk r230722 and r230725 with the existing Fortran OpenACC > declare implementation present on gomp-4_0-branch, I effectively applied > the following to gomp-4_

[committed] Add 'libgomp.oacc-fortran/allocatable-array-1.f90' (was: [gomp4] Properly handle allocatable scalars in acc update)

Hi! On Thu, 8 Jun 2017 14:40:29 -0700, Cesar Philippidis wrote: > This patch fixes a bug I introduced while [...] > libgomp/ > * testsuite/libgomp.oacc-fortran/allocatable-array-1.f90: New test. This test case actually PASSes with current trunk, committed in r272448 "Add 'libgomp.o

[PR90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable (was: [patch,gomp4] make fortran loop variables implicitly private in openacc)

Hi! On Mon, 11 Aug 2014 16:55:28 -0700, Cesar Philippidis wrote: > According to section 2.6.1 in the openacc spec, fortran loop variables > should be implicitly private like in openmp. More correctly, they are "predetermined private" (which cannot be overridden), not "implicit private" (which c

[PR72741] Properly handle clauses specifying the level of parallelism for 'external' Fortran OpenACC routines (was: [gomp4] check for sufficient parallelism when calling acc routines in fortran)

Hi! On Fri, 26 Aug 2016 08:16:43 -0700, Cesar Philippidis wrote: > This patch (..., variants of which got re-submitted a few times, later on...) > teaches the fortran FE how to verify that there is sufficient > parallelism when calling acc routines inside acc loop. E.g. the fortran > FE will n

Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"

Hi! On Thu, 21 Jan 2016 22:54:26 +0100, I wrote: > Committed to gomp-4_0-branch in r232709: > > commit 41a76d233e714fd7b79dc1f40823f607c38306ba > Author: tschwinge > Date: Thu Jan 21 21:52:50 2016 + > > Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid > offloa

Re: [gomp4] backport firstprivate subarray changes

Hi! On Fri, 27 May 2016 08:19:56 -0700, Cesar Philippidis wrote: > This patch backports the recent firstprivate subarray changes I've made > [...] > Thomas, I decided to xfail a bunch of kernels tests in gomp4 instead of > removing them so that we can have a better recor

OpenACC ICV acc-default-async-var (was: [gomp4] Async related additions to OpenACC runtime library)

Hi Chung-Lin! On Mon, 13 Feb 2017 18:13:42 +0800, Chung-Lin Tang wrote: > This patch adds: > > // New functions to set/get the current default async queue > void acc_set_default_async (int); > int acc_get_default_async (void); > > and _async versions of a few existing API functions: (Please,

Re: [gomp4] OpenACC async re-work

On 10/10/2017 11:08 AM, Thomas Schwinge wrote: > Reported by Cesar for a test case similar to the one below, where we > observe: > > acc_prof-cuda-1.exe: [...]/libgomp/oacc-profiling.c:592: > goacc_profiling_dispatch_p: Assertion `thr->prof_info == NULL' failed. > > This is because of: > >

Re: [gomp4] OpenACC async re-work

Hi! Reported by Cesar for a test case similar to the one below, where we observe: acc_prof-cuda-1.exe: [...]/libgomp/oacc-profiling.c:592: goacc_profiling_dispatch_p: Assertion `thr->prof_info == NULL' failed. This is because of: On Tue, 25 Jul 2017 20:51:05 +0800, Chung-Lin Tang wrote:

Re: [gomp4] OpenACC async re-work

On 2017/7/25 10:09 PM, Cesar Philippidis wrote: > On 07/25/2017 05:51 AM, Chung-Lin Tang wrote: >> On 2017/6/29 6:31 AM, Cesar Philippidis wrote: > >> Attached is the updated version of the patch, re-tested. >> >> Thomas, do you need some more time to look over it? Or should I commit it >> first?

Re: [gomp4] OpenACC async re-work

On 07/25/2017 05:51 AM, Chung-Lin Tang wrote: > On 2017/6/29 6:31 AM, Cesar Philippidis wrote: > Attached is the updated version of the patch, re-tested. > > Thomas, do you need some more time to look over it? Or should I commit it > first? I'm not too concerned about the profiling stuff becaus

Re: [gomp4] OpenACC async re-work

On 2017/6/29 6:31 AM, Cesar Philippidis wrote: > 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

[gomp4, nvptx, committed] Fix --enable-checking=rtl assert in nvptx_propagate_unified

[ was: Re: [gomp4, nvptx, committed] Fix assert in nvptx_propagate_unified ] On 07/06/2017 09:15 AM, Thomas Schwinge wrote: Hi Tom! On Fri, 30 Jun 2017 17:15:24 +0200, Tom de Vries wrote: with the openacc test-case in attached patch, I ran into an assert here: Using your test case, in my

Re: [gomp4, nvptx, committed] Fix assert in nvptx_propagate_unified

Hi Tom! On Fri, 30 Jun 2017 17:15:24 +0200, Tom de Vries wrote: > with the openacc test-case in attached patch, I ran into an assert here: Using your test case, in my build with "--enable-checking=yes,df,fold,rtl", I already earlier run into an ICE... > static void > nvptx_propagate_unified (rt

Re: [gomp4] fix an ICE involving assumed-size arrays

Hi! On Tue, 30 Aug 2016 14:55:06 -0700, Cesar Philippidis wrote: > Usually a data clause would would have OMP_CLAUSE_SIZE set, but not all > do. In the latter case, lower_omp_target falls back to using size of the > type of the variable specified in the data clause. However, in the case > of ass

[gomp4, nvptx, committed] Fix assert in nvptx_propagate_unified

Hi, with the openacc test-case in attached patch, I ran into an assert here: ... static void nvptx_propagate_unified (rtx_insn *unified) { rtx_insn *probe = unified; rtx cond_reg = SET_DEST (PATTERN (unified)); rtx pat; /* Find the comparison. (We could skip this and simply scan to

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 >>> by the plugin, along with core 'test', 'synchron

Re: [gomp4] OpenACC async re-work

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 >> by the plugin, along with core 'test', 'synchronize', 'serialize', etc. >> plugin functions. Most o

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-

[gomp4] Properly handle allocatable scalars in acc update.

This patch fixes a bug I introduced while adding support for allocatable scalars back in April. Before, gfc_trans_oacc_executable_directive would indiscriminately promote all GOMP_MAP_FIRSTPRIVATE_POINTER data mappings to GOMP_MAP_ALWAYS_POINTER, because for allocatable scalars the runtime needs to

Re: [gomp4] Implement OpenACC 2.5 reference counting, and finalize clause

Hi! On Tue, 16 May 2017 20:55:46 +0800, Chung-Lin Tang wrote: > finalize clause of the exit data directive, and the > corresponding API routines. > --- libgomp/oacc-parallel.c (revision 248095) > +++ libgomp/oacc-parallel.c (revision 248096) > @@ -355,7 +355,22 @@ > } > } >el

Re: [gomp4] Implement OpenACC 2.5 reference counting, and finalize clause

Hi! On Tue, 16 May 2017 20:55:46 +0800, Chung-Lin Tang wrote: > finalize clause of the exit data directive Thanks! > --- libgomp/oacc-parallel.c (revision 248095) > +++ libgomp/oacc-parallel.c (revision 248096) > void > GOACC_enter_exit_data (int device, size_t mapnum, >

Re: [gomp4] Implement OpenACC 2.5 reference counting, and finalize clause

Hi! On Tue, 16 May 2017 20:55:46 +0800, Chung-Lin Tang wrote: > finalize clause of the exit data directive This would run into ICEs in the C++ front end (template handling) as well as C and Fortran front ends (nested function handling), and didn't pretty-print the "finalize" clause. Also test

Re: [gomp4] Implement OpenACC 2.5 reference counting, and finalize clause

Hi! On Tue, 16 May 2017 20:55:46 +0800, Chung-Lin Tang wrote: > finalize clause of the exit data directive The OpenACC front end code currently maps the OpenACC delete clause to "OMP_CLAUSE_DELETE" -- however, without a finalize clause, this clause actually has "OMP_CLAUSE_RELEASE" semantics.

Re: [gomp4] backport misc OMP 4.5 changes from trunk

Hi! On Wed, 15 Mar 2017 07:21:26 -0700, Cesar Philippidis wrote: > This patch backports Jakub's Fortran OMP 4.5 changes to gomp-4_0-branch. > The original patch may be found here > . I've applied > it to gomp-4_0-branch. > --- a/gcc/fort

Re: [gomp4] Update libgomp documentation

On Tue, 16 May 2017, Cesar Philippidis wrote: > Arguably, I probably should have split the backport into a separate > patch. However, I think this only impacts libgomp. And I was tempted to > just to copy the complete texinfo.tex file from texinfo 6.3, like it was > last done in 2012. However, I w

[gomp4] Update libgomp documentation

This patch does two things: 1. Updates the libgomp documentation to reflect the recent OpenACC 2.5 changes. 2. Backports a texinfo patch to wrap the title of the libgomp manual in the pdf. Without it, part of the title would get truncated out of the page. For the most part, the gom

[gomp4] Implement OpenACC 2.5 reference counting, and finalize clause

This patch for gomp-4_0-branch implements OpenACC 2.5 reference counting of mappings, the finalize clause of the exit data directive, and the corresponding API routines. Tested without regressions, committed to gomp-4_0-branch. Chung-Lin 2017-05-16 Chung-Lin Tang gcc/c/ * c-p

[gomp4] Handle parallel reductions explicitly initialized by the user

This patch resolves an ICE inside the nvptx BE involving reduction variables which are initialized by the user. E.g. #pragma acc parallel reduction(+:var) { var = 1; #pragma acc loop reduction(+:var) ... Currently, the nvptx BE expects the internal function GOACC_REDUCTION to hav

[gomp4] correct an implicit data clause bug

I introduced a subtle bug in my fix for pr70828. That PR involved implicit data mappings of subarrays which the user had explicitly mapped inside an enclosing acc data region. E.g. #pragma acc data copy(a[5:10]) { #pragma acc parallel loop for (...) a[i] = ... My fix for the PR

[gomp4] OpenACC update if_present runtime support

This patch adds runtime support for the OpenACC update if_present clause. It turned out to require significantly less work to implement if_present in the runtime. Instead of creating a new API for GOACC_updated, I exploited the fact that OpenACC no longer uses GOMP_MAP_FORCE_* data mappings. This a

Re: [gomp4] Add front end support for the if_present clause with the update directive

Hi! On Thu, 4 May 2017 15:11:30 -0700, Cesar Philippidis wrote: > This patch make the c, c++ and fortran FEs aware of the new OpenACC 2.5 > if_present clause for the update directive. Thanks! > The ME and runtime support > will come in a separate followup patch. > Thomas, for some reason I'm

[gomp4] Add front end support for the if_present clause with the update directive

This patch make the c, c++ and fortran FEs aware of the new OpenACC 2.5 if_present clause for the update directive. The ME and runtime support will come in a separate followup patch. Thomas, for some reason I'm seeing a couple of new UNRESOLVED tests for update-1.C. The c++ tests running with goac

[gomp4] Don't mark OpenACC auto loops as independent inside acc parallel regions

The OpenACC 2.5 spec updated the behavior of acc loops inside acc parallel regions such that loop with seq and auto clauses are not implicitly independent. Back in OpenACC 2.0, all loops inside acc parallel regions were implicitly independent. Oddly enough, if the user just places an acc loop witho

[gomp4] Make front ends emit warnings when OpenACC routines directives lack parallelism

The language regarding OpenACC routines have changed in OpenACC 2.5 such that the end user must explicitly specify one of gang, worker, vector or seq partitioning. I guess some other compiler need those directives to generate specialized versions of those functions accordingly. However, GCC current

[gomp4] Make OpenACC orphan gang reductions errors

This patch promotes all OpenACC gang reductions on orphan loops as errors. Accord to the spec, orphan loops are those which are not lexically nested inside an OpenACC parallel or kernels regions. I.e., acc loops inside acc routines. At first I thought this could be a warning because the gang reduc

[gomp4] Fix an ICE involving OpenACC routines inside broken fortran functions.

I encountered an ICE when the fortran FE tries to parse an OpenACC routine directive when the containing function has a syntax error. E.g. integer function f1 is missing an argument list, so the fortran FE will not create a function symbol for f1. Consequently, the OpenACC routine parser cannot

[gomp4] Update error messages for c and c++ reductions

This patches updates the c and c++ FEs to report consistent error messages for invalid reductions involving array elements, struct members, and class members. Most of those variables were already rejected by the generic OpenMP code, but this patch makes the error messages more precise for OpenACC.

Re: [gomp4] add support for allocatable scalars in OpenACC declare constructs

data >> map.declare_allocate" 1 "original" } } >> -! { dg-final { scan-tree-dump-times "pragma acc exit data >> map.declare_deallocate" 1 "original" } } >> +! { dg-final { scan-tree-dump-times "pragma acc enter data >> map.decla

Re: [gomp4] add support for allocatable scalars in OpenACC declare constructs

Hi! On Wed, 19 Apr 2017 11:11:39 -0700, Cesar Philippidis wrote: > I've applied this patch to gomp-4_0-branch to add support for fortran > allocatable scalars inside OpenACC declare constructs. Thanks! > Included in this patch is a bug fix for non-declared allocatable > scalars. [...] Please

[gomp4] add support for allocatable scalars in OpenACC declare constructs

I've applied this patch to gomp-4_0-branch to add support for fortran allocatable scalars inside OpenACC declare constructs. In order to update the declared variable on the device, the fortran FE now uses the GOMP_MAP_ALWAYS_POINTERS for declared allocatable scalars. That necessitated some minor tw

[patch, gomp4, committed] Adjust copy/copyin/copyout/create for OpenACC 2.5

The behavior of the copy/copyin/copyout/create clauses has been changed in OpenACC 2.5 to be like the present_or_* variants, and the original present_or_* syntax relegated to legacy status. This patch removes the presence of any PRESENT_OR_* symbols, and changes the mapping of the copy/copyin/copy

Re: [patch,gomp4] add support for fortran common blocks

Hi Cesar! On Wed, 5 Apr 2017 13:37:30 -0700, Cesar Philippidis wrote: > On 04/05/2017 01:22 PM, Thomas Schwinge wrote: > > >> --- a/gcc/gimplify.c > >> +++ b/gcc/gimplify.c > >> @@ -6102,14 +6102,19 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, > >> tree decl, unsigned flags) > >> { >

Re: [gomp4] add support for fortran allocate support with declare create

On 04/06/2017 02:05 AM, Thomas Schwinge wrote: >> --- /dev/null >> +++ b/gcc/testsuite/gfortran.dg/goacc/declare-allocatable-1.f90 >> @@ -0,0 +1,25 @@ >> +! Verify that OpenACC declared allocatable arrays have implicit >> +! OpenACC enter and exit pragmas at the time of allocation and >> +! deallo

Re: [gomp4] add support for fortran allocate support with declare create

Hi Cesar! On Wed, 5 Apr 2017 08:23:58 -0700, Cesar Philippidis wrote: > This patch implements the OpenACC 2.5 behavior of fortran allocate on > variables marked with declare create as defined in Section 2.13.2 in the > OpenACC spec. Thanks! > While working on adding support for allocate, I no

Re: [patch,gomp4] add support for fortran common blocks

On 04/05/2017 01:22 PM, Thomas Schwinge wrote: >> --- a/gcc/gimplify.c >> +++ b/gcc/gimplify.c >> @@ -6102,14 +6102,19 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, >> tree decl, unsigned flags) >> { >>const char *rkind; >>bool on_device = false; >> + bool is_private = false; >

Re: [patch,gomp4] add support for fortran common blocks

Hi Cesar! Can you please help me understand/verify a part of your patch: On Thu, 15 Sep 2016 07:56:58 -0700, Cesar Philippidis wrote: > Currently gfortran largely lacks support for fortran common blocks in > OpenACC. The notable exception is acc declare link which does support > common block ar

[gomp4] add support for fortran allocate support with declare create

This patch implements the OpenACC 2.5 behavior of fortran allocate on variables marked with declare create as defined in Section 2.13.2 in the OpenACC spec. To do so, I've added two new data mappings, GOMP_MAP_DECLARE_ALLOCATE and GOMP_MAP_DECLARE_DEALLOCATE. While working on adding support for al

Re: [gomp4] backport misc OMP 4.5 changes from trunk

On 03/16/2017 07:13 AM, Thomas Schwinge wrote: >> --- a/gcc/gimplify.c >> +++ b/gcc/gimplify.c > >> @@ -6636,9 +6596,9 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq >> *pre_p, >>ctx = new_omp_context (region_type); >>ctx->clauses = *list_p; >>outer_ctx = ctx->outer_context;

[gomp4] update parsing for the bind clause in fortran

This patch does the following: * Update gfortran's bind parser to allow the bind with a string argument to be used with 'implicit none' * Teaches gfortran how to lower the bind clause like the c and c++ front ends. Note that the bind clause still isn't implemented in the middle end. Also,

[gomp4] fix an ICE involving derived-typed subarray

I'll apply this patch to gomp-4_0-branch shortly which fixes an ICE triggered by using data clauses with derived-type subarray arguments. Such subarrays can be handled generically. Cesar 2017-03-31 Cesar Philippidis gcc/fortran/ * trans-openmp.c (gfc_trans_omp_clauses_1): Update handling of

Re: [gomp4] backport misc OMP 4.5 changes from trunk

Hi Cesar! On Wed, 15 Mar 2017 07:21:26 -0700, Cesar Philippidis wrote: > This patch backports Jakub's Fortran OMP 4.5 changes to gomp-4_0-branch. > The original patch may be found here > . I've applied > it to gomp-4_0-branch. Thanks! A

[gomp4] cleanup trans-stmt.h

I noticed that gcc/fortran/trans-stmt.h made a reference to a non-existent trans-openacc.c. Those functions have been placed in trans-openmp.c. This patch has been applied to gomp-4_0-branch to correct that error. Cesar 2017-03-14 Cesar Philippidis gcc/fortran/ * trans-stmt.h: Remove stale r

[gomp4] add support for gang local storage allocation in shared memory

This patch, which is largely implemented by Chung-Lin, is a first step towards teaching the c and c++ FEs how to allocate shared memory for gang local variables. E.g. #pragma acc parallel { int some_array[N], some_var; Both some_array and some_var will be stored in shared memory with this

Re: [gomp4] DEV-PHASE change

ether certain files in the compiler are built with -Werror in bootstrap stage2 and later. If you don't specify it, -Werror is turned on for the main development trunk. However it defaults to off for release branches and final releases. The specific files which get -Werror are controlled by

Re: [gomp4] DEV-PHASE change

Hi Tom! On Thu, 23 Feb 2017 17:19:37 +0100, Tom de Vries wrote: > [ was: r241221 [1/2] - in /branches/gomp-4_0-branch: ] > > On 16/10/16 22:13, tschwi...@gcc.gnu.org wrote: > > Author: tschwinge > > Date: Sun Oct 16 20:13:18 2016 > > New Revision: 241221 > > > > URL: https://gcc.gnu.org/vie

[gomp4] DEV-PHASE change

[ was: r241221 [1/2] - in /branches/gomp-4_0-branch: ] On 16/10/16 22:13, tschwi...@gcc.gnu.org wrote: Author: tschwinge Date: Sun Oct 16 20:13:18 2016 New Revision: 241221 URL: https://gcc.gnu.org/viewcvs?rev=241221&root=gcc&view=rev Log: svn merge -r 235033:240831 svn+ssh://gcc.gnu.org/s

Re: [gomp4] add -finform-parallelism

On 02/22/2017 12:17 AM, Thomas Schwinge wrote: > On Mon, 20 Feb 2017 20:42:59 -0800, Cesar Philippidis > wrote: >> --- a/gcc/omp-low.c >> +++ b/gcc/omp-low.c > >> +/* Provide diagnostics on OpenACC loops LOOP, its siblings and its >> + children. */ >> + >> +static void >> +inform_oacc_loop (

[gomp4] backport OPTGROUP_OPENMP

This patch backports OPTGROUP_OPENMP from trunk. The patch was originally posted by Martin Jambor here . Thomas, I know that you have a patch to rename this to OPTGROUP_OMP. But in order to keep things consistent with trunk, I kept it OPTGR

[gomp4] delete unused variable inside trans-openmp.c

I've applied this patch to gomp-4-0-branch to remove an unused variable inside trans-openmp.c. I'm not sure why bootstrapping does catch this sort of error anymore. Maybe my build script of overriding the build flags some how. Cesar 2017-02-22 Cesar Philippidis gcc/fortran/ * trans-openmp.c

[gomp4] correct the reported line number in fortran combined OpenACC directives

Like its c++ counterpart, the fortran FE incorrectly records the line locations of combined acc loop directives when it lowers the construct to gimple. Usually this isn't a problem because the fortran FE is able to report problems with acc loops itself. However, there will be inaccuracies if the ME

[gomp4] correct the reported line number in c++ combined OpenACC directives

The C++ FE isn't setting the expr_location of the split acc loop in combined acc parallel/kernels loop directives. This only happens for with combined directives, otherwise cp_parser_omp_construct would be responsible for setting the location. After fixing this bug, I was able to resolve a couple o

Re: [gomp4] add -finform-parallelism

Hi Cesar! On Mon, 20 Feb 2017 20:42:59 -0800, Cesar Philippidis wrote: > This patch introduces a new -finform-parallelism flag to report any > detected parallelism encountered by the compiler. Initially, it's being > used to report how oaccdevlow partitions OpenACC loops. Currently, if > you wan

[gomp4] add -finform-parallelism

This patch introduces a new -finform-parallelism flag to report any detected parallelism encountered by the compiler. Initially, it's being used to report how oaccdevlow partitions OpenACC loops. Currently, if you want to extract this information, you need to compile the program with -fdump-tree-oa

Re: [gomp4] adjust num_gangs and add a diagnostic for unsupported num_workers

On Fri, 17 Feb 2017, Cesar Philippidis wrote: > > And then, I don't specifically have a problem with discontinuing CUDA 5.5 > > support, and require 6.5, for example, but that should be a conscious > > decision. > > We should probably ditch CUDA 5.5. In fact, according to trunk's cuda.h, > it requ

Re: [gomp4] adjust num_gangs and add a diagnostic for unsupported num_workers

On 02/15/2017 01:29 PM, Thomas Schwinge wrote: > On Mon, 13 Feb 2017 08:58:39 -0800, Cesar Philippidis > wrote: >> @@ -952,25 +958,30 @@ nvptx_exec (void (*fn), size_t mapnum, void >> **hostaddrs, void **devaddrs, >>CUdevice dev = nvptx_thread()->ptx_dev->dev; >>/* 32 is the def

Re: [gomp4] adjust num_gangs and add a diagnostic for unsupported num_workers

Hi Cesar! On Mon, 13 Feb 2017 08:58:39 -0800, Cesar Philippidis wrote: > This patch does the followings: > > * Adjusts the default num_gangs to utilize more of GPU hardware. > * Teach libgomp to emit a diagnostic when num_workers isn't supported. > > [...] Thanks! > This patch has been app

Re: [gomp4] Async related additions to OpenACC runtime library

Hi! On Tue, 14 Feb 2017 19:58:11 +0800, Chung-Lin Tang wrote: > On 2017/2/14 07:25 PM, Thomas Schwinge wrote: > > Testing [...], I saw a lot of regressions, > > and in r245427 just committed [...] to address > > these. Did you simply forget to commit your changes to > > libgomp/libgomp.map, or

Re: [gomp4] Async related additions to OpenACC runtime library

On 2017/2/14 07:25 PM, Thomas Schwinge wrote: > Hi Chung-Lin! > > On Mon, 13 Feb 2017 18:13:42 +0800, Chung-Lin Tang > wrote: >> Tested and committed to gomp-4_0-branch. > > Thanks! (Not yet reviewed.) Testing this, I saw a lot of regressions, > and in r245427 just committed the following to

Re: [gomp4] Async related additions to OpenACC runtime library

Hi Chung-Lin! On Mon, 13 Feb 2017 18:13:42 +0800, Chung-Lin Tang wrote: > Tested and committed to gomp-4_0-branch. Thanks! (Not yet reviewed.) Testing this, I saw a lot of regressions, and in r245427 just committed the following to gomp-4_0-branch to address OCthese. Did you simply forget to

[gomp4] adjust num_gangs and add a diagnostic for unsupported num_workers

This patch does the followings: * Adjusts the default num_gangs to utilize more of GPU hardware. * Teach libgomp to emit a diagnostic when num_workers isn't supported. According to the confusing CUDA literature, it appears that the previous num_gangs wasn't fully utilizing the GPU hardware. The

[gomp4] Async related additions to OpenACC runtime library

This patch adds: // New functions to set/get the current default async queue void acc_set_default_async (int); int acc_get_default_async (void); and _async versions of a few existing API functions: void acc_copyin_async (void *, size_t, int); void acc_create_async (void *, size_t, int); void acc

Re: [gomp4] enable GOMP_MAP_FIRSTPRIVATE_INT in OpenACC

On 30/01/17 11:18, Thomas Schwinge wrote: +static tree +convert_from_firstprivate_pointer (tree var, bool is_ref, gimple_seq *gs) +{ + tree type = TREE_TYPE (var); + tree new_type = NULL_TREE; + tree tmp = NULL_TREE; + tree inner_type = NULL_TREE; [...]/source-gcc/gcc/omp-low.c: In funct

[gomp4] fix a reduction bug involving GOMP_MAP_FIRSTPRIVATE_POINTER variables

This patch teaches lower_oacc_reductions how to handle reduction variables that were transferred to the accelerator via GOMP_MAP_FIRSTPRIVATE_POINTER, e.g. fortran dummy variables. One side effect of this change is that the ref_to_res variable gets remapped to the (void *) field decl that gets tran

Re: [gomp4] optimize GOMP_MAP_TO_PSET

On 01/30/2017 02:26 AM, Thomas Schwinge wrote: > ... also there is some bug somewhere; I see: > > PASS: libgomp.fortran/examples-4/async_target-2.f90 -O0 (test for > excess errors) > [-PASS:-]{+FAIL:+} libgomp.fortran/examples-4/async_target-2.f90 -O0 > execution test > PASS:

Re: [gomp4] enable GOMP_MAP_FIRSTPRIVATE_INT in OpenACC

On 01/30/2017 02:18 AM, Thomas Schwinge wrote: > Hi Cesar! > > On Fri, 27 Jan 2017 07:45:52 -0800, Cesar Philippidis > wrote: >> If you take a close look at lower_omp_target, you'll notice that I'm >> gave reference types special treatment. Specifically, I disabled this >> optimization on non-IN

Re: [gomp4] add support for derived types in ACC UPDATE

>> + gfc_ref *ref = n->expr->ref; >> + tree orig_decl = decl; > > [...]/source-gcc/gcc/fortran/trans-openmp.c: In function 'tree_node* > gfc_trans_omp_clauses_1(stmtblock_t*, gfc_omp_clauses*, locus, bool)': > [...]/source-gcc/gcc

Re: [gomp4] optimize GOMP_MAP_TO_PSET

Hi Cesar! On Mon, 30 Jan 2017 07:19:27 -0800, Cesar Philippidis wrote: > On 01/30/2017 02:26 AM, Thomas Schwinge wrote: > > On Fri, 27 Jan 2017 08:06:22 -0800, Cesar Philippidis > > wrote: > > PASS: libgomp.fortran/examples-4/async_target-2.f90 -O0 (test for > > excess errors) > >

Re: [gomp4] partially enable GOMP_MAP_FIRSTPRIVATE_POINTER in gfortran

Hi Cesar! (It's me, again!) ;-) On Fri, 27 Jan 2017 09:13:06 -0800, Cesar Philippidis wrote: > This patch partially enables GOMP_MAP_FIRSTPRIVATE_POINTER in gfortran. > gfortran still falls back to GOMP_MAP_POINTER for arrays with > descriptors and derived types. The limitation on derived type

Re: [gomp4] optimize GOMP_MAP_TO_PSET

if the host were to run in multi-threaded applications. >> Maybe I'll drop this patch from gomp4 since it's not very effective. > > ... also there is some bug somewhere; I see: > > PASS: libgomp.fortran/examples-4/async_target-2.f90 -O0 (test for > exces

Re: [gomp4] optimize GOMP_MAP_TO_PSET

ing the host's > copy of the PSET prior to uploading it. The host's PSET does get > restored prior to returning from gomp_map_vars, however that might > impact things if the host were to run in multi-threaded applications. > Maybe I'll drop this patch from gomp4 since it&

Re: [gomp4] enable GOMP_MAP_FIRSTPRIVATE_INT in OpenACC

Hi Cesar! On Fri, 27 Jan 2017 07:45:52 -0800, Cesar Philippidis wrote: > If you take a close look at lower_omp_target, you'll notice that I'm > gave reference types special treatment. Specifically, I disabled this > optimization on non-INTEGER_TYPE and floating point values, because the > nvptx

Re: [gomp4] add support for derived types in ACC UPDATE

Hi Cesar! On Thu, 10 Nov 2016 09:38:33 -0800, Cesar Philippidis wrote: > This patch has been committed to gomp-4_0-branch. > --- a/gcc/fortran/openmp.c > +++ b/gcc/fortran/openmp.c > @@ -242,7 +243,8 @@ gfc_match_omp_variable_list (const char *str, > gfc_omp_namelist **list, > case MATC

[gomp4] partially enable GOMP_MAP_FIRSTPRIVATE_POINTER in gfortran

This patch partially enables GOMP_MAP_FIRSTPRIVATE_POINTER in gfortran. gfortran still falls back to GOMP_MAP_POINTER for arrays with descriptors and derived types. The limitation on derived types is there because we don't have much test coverage for it, and this patch series was more exploratory f

[gomp4] optimize GOMP_MAP_TO_PSET

t impact things if the host were to run in multi-threaded applications. Maybe I'll drop this patch from gomp4 since it's not very effective. Cesar

[gomp4] enable GOMP_MAP_FIRSTPRIVATE_INT in OpenACC

This patch does the following two things: 1) Enable GOMP_MAP_FIRSTPRIVATE_INT in OpenaCC. 2) Extends the 'INT' values to handle floats and doubles via type casting. OpenACC handles OMP_CLAUSE_FIRSTPRIVATE slightly different to OpenMP; lower_omp_target changes it to a data map clause. Conseq

Re: [gomp4] don't error on implicitly private induction variables in gfortran

On 01/27/2017 07:07 AM, Jakub Jelinek wrote: > On Fri, Jan 27, 2017 at 07:02:45AM -0800, Cesar Philippidis wrote: >> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c >> index 61940d7..2782a8d 100644 >> --- a/gcc/fortran/openmp.c >> +++ b/gcc/fortran/openmp.c >> @@ -5192,7 +5192,8 @@ gfc_re

Re: [gomp4] don't error on implicitly private induction variables in gfortran

On Fri, Jan 27, 2017 at 07:02:45AM -0800, Cesar Philippidis wrote: > While experimenting with some new OpenACC benchmarks, I noticed that > gfortran errors when the user explicitly marks loop induction variables > as private. I applied this patch to gomp-4_0-branch to resolve that problem. > > Ces

[gomp4] don't error on implicitly private induction variables in gfortran

While experimenting with some new OpenACC benchmarks, I noticed that gfortran errors when the user explicitly marks loop induction variables as private. I applied this patch to gomp-4_0-branch to resolve that problem. Cesar 2017-01-26 Cesar Philippidis gcc/fortran/ * openmp.c (gfc_resolve_oa

Re: [gomp4] remove GOVD_USE_DEVPTR

Hi! On Mon, 7 Nov 2016 12:45:43 -0800, Cesar Philippidis wrote: > It looks like gomp-4_0-branch was using the GOVD_USE_DEVPTR attribute [...] > I've applied this patch remove GOVD_USE_DEVPTR from gomp4. I'm seeing: [...]/gcc/gimplify.c: In function 'int gimplify

Re: [gomp4] remove GOVD_USE_DEVPTR

Hi! On Mon, 7 Nov 2016 12:45:43 -0800, Cesar Philippidis wrote: > It looks like gomp-4_0-branch was using the GOVD_USE_DEVPTR attribute [...] > I've applied this patch remove GOVD_USE_DEVPTR from gomp4. > 2016-11-07 Cesar Philippidis > > gcc/fortran

[gomp4] Support multi-dimensional pointer based arrays in OpenACC data clauses

This patch implements support for dynamically allocated multi-dimensional arrays in OpenACC data clauses. To illustrate, these kinds of arrays now work: int **a; float *f[100]; double ***d; #pragma acc parallel copy (a[0:100][x:y], f[10:20][0:30]) copyout(d[x:y][x:y][x:y]) { ... } The pointer-

[gomp4] backport an acc directive matching cleanup for fortran

This patch contains a backport of the fortran OpenACC directive matching changes I made to trunk here <https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01286.html>. It's not a clean backport because gomp4 has some support for the device_type clause which is missing in trunk. Next I plan

[gomp4] fix implicit data clause linker error

The patch I introduced here to fix PR70828 in gomp-4_0-branch has a bug involving the creation of new implicit data clauses for variables inside ACC PARALLEL or KERNELS regions that are present inside an enclosing ACC DATA region. Specifica

[gomp4] remove use of CUDA unified memory in libgomp

This patch eliminates the use of CUDA unified shared memory via cuMemcpy inside nvptx_exec. The major problem with unified memory is that the CUDA driver needs to copy all of the host addresses to a special data region prior to transferring the data to and from the accelerator. I'm not sure why the

  1   2   3   4   5   6   7   8   9   10   >