Re: [gomp4] fix spinlock

olution ok as-is for gomp-4_0-branch? Thanks, Cesar 2015-08-06 Cesar Philippidis gcc/ * config/nvptx/nvptx.c (nvptx_expand_lock_unlock): Pass an additional scratch register to gen_nvptx_spinlock. * config/nvptx/nvptx.md (nvptx_membar): Use %B for the address space operand. (nvptx_spinlock

Re: [gomp4] Add new oacc_transform patch

On 07/28/2015 02:21 AM, Thomas Schwinge wrote: > Cesar, please address the following compiler diagnostig: > >> 2015-07-21 Cesar Philippidis >> >> gcc/ >> * omp-low.c (execute_oacc_transform): New function. >> (clas

Re: [gomp4] acc routines bugfix

On 07/24/2015 08:21 AM, Ilya Verbin wrote: > On Fri, Jul 24, 2015 at 08:05:00 -0700, Cesar Philippidis wrote: >> The second point is interesting. Offloaded functions require the "omp >> target" attribute or that function won't reach the lto compiler. That's

[gomp4] acc routines bugfix

ves having two compilers present. I wonder if it's ok to have libgomp check for compiler expected compiler errors? However, that's more of a gcc/testsuite type of check. I don't think trunk has much support for acc routines just yet, so I applied this patch to gomp-4_0-branch for

Re: [patch] PR66714 -- Re: Re: [RFC] two-phase marking in gt_cleare_cache

On 07/23/2015 03:11 PM, Jakub Jelinek wrote: > On Thu, Jul 23, 2015 at 03:01:25PM -0700, Cesar Philippidis wrote: >> On 07/23/2015 08:32 AM, Jakub Jelinek wrote: >>> On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote: >>>> The attached pa

Re: [patch] PR66714 -- Re: Re: [RFC] two-phase marking in gt_cleare_cache

On 07/23/2015 08:32 AM, Jakub Jelinek wrote: > On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote: >> The attached patch does just that; it teaches >> replace_block_vars_by_duplicates to replace the decls inside the >> value-exprs with a duplicate too. It'

[patch] PR66714 -- Re: Re: [RFC] two-phase marking in gt_cleare_cache

nd MEM_REFs. I suspect that I may be missing some, but these are the only ones that were triggered gcc_unreachable during testing. As Tom mentioned in PR66714, this bug is present on trunk, specifically in code using omp targets. Is this patch OK for trunk? I bootstrapped and tested on x86_64-li

[gomp4] Add new oacc_transform patch

27;m expanding those calls using target machine hooks. This pass will run after lto on the target compiler. Thanks, Cesar 2015-07-21 Cesar Philippidis gcc/ * omp-low.c (execute_oacc_transform): New function. (class pass_oacc_transform): New function. (make_pass_oacc_transform): New function

[gomp4] cleanup firstprivate test case

15-07-17 Cesar Philippidis libgomp/ * testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c: Remove omp pragma. diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c index e5fc6a0..69abb23 100644 --- a/li

[gomp4] OpenACC reduction tests

too confusing too debug. The fortran tests are a bit of a lost clause, unless someone knows how to use the preprocessor with !$acc loops. Cesar 2015-07-17 Cesar Philippidis libgomp/ * testsuite/libgomp.oacc-c-c++-common/reduction.h: New file. * testsuite/libgomp.oacc-c-c++-common/reduction-1

[gomp4] OpenACC vector and worker reductions

e welcome. Is this reduction scheme too nvptx-specific? I'll post the test cases in a follow up patch because the patch would be too big for the mailing list otherwise. Thanks, Cesar 2015-07-17 Cesar Philippidis gcc/ * config/nvptx/nvptx.c (nvptx_generate_vector_shuffle): New fun

Re: [gomp4, fortran] Patch to fix continuation checks of OpenACC and OpenMP directives

t;>> >>> Thanks for your review! >>> >>> 08.06.2015, 17:59, "Cesar Philippidis" : >>>> On 06/07/2015 02:05 PM, Ilmir Usmanov wrote: >>>>>Fixed fortran mail-list address. Sorry for inconvenience. >>>>> >>&

Re: [gomp4] Allow parameter declarations with deviceptr

On 07/01/2015 02:25 PM, James Norris wrote: > This patch allows parameter declarations to be used as > arguments to deviceptr for C and C++. Does this fix an existing failure? If not, can you please add a new test case? Thanks, Cesar

Re: [gomp] openacc reduction cleanup

On 06/30/2015 11:01 AM, Cesar Philippidis wrote: > This patch has been applied to gomp-4_0-branch. It was brought to my attention that I forgot to attach the patch. Cesar 2015-06-30 Cesar Philippidis gcc/ * omp-low.c (oacc_get_reduction_array_id): Rem

Re: [committed,gomp4] Run testsuite/libgomp.oacc-c++/c++.exp at -O2 by default

On 06/30/2015 02:30 PM, Tom de Vries wrote: > diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-1.c > b/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-1.c > index 144f892..6b22e7f 100644 > --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-1.c > +++ b/libgomp/testsuite/l

[gomp] openacc reduction cleanup

This patch removes a lot of the crufty code which was necessary for an arbitrary sized vector reductions. The new plan going forward it to fix vector_length to a size such that vector loops don't require any synchronization after the loop have terminated. In the case of nvptx targets, vector_length

[gomp4] use static_nonchunk loop scheduling for non-static acc gang loops

ng on gpus. I also updated the nvptx-specific gang loop test case. My first attempt wasn't scanning all of the values in the array. This corrects that, and it also teaches that test what to expect for gang(static:*). This patch has been committed to gomp-4_0-branch. Cesar 2015-06-17 Cesar P

[gomp4] c/c++ cleanups for openacc combined loops

ls to c_finish_omp_clauses and finish_omp_clauses. But those are the only two isolated cases. I've also added a c_ prefix to oacc_filter_device_types because that how the other functions in c-omp.c are named. I've applied this patch to gomp-4_0-branch. Cesar 2015-06-15 Cesar Philippidis gcc

[gomp4] initial support for openacc worker state propagation

variables simultaneously. So instead, all of the variables are broadcasted sequentially for the moment. A follow up patch at a later date will address this issue. This patch has been applied to gomp-4_0-branch. Cesar 2015-06-15 Cesar Philippidis gcc/ * omp-low.c (expand_omp_for_static_nochunk

[gomp4] error on duplicate acc device_type entries

in the fortran front end. It used report "Invalid character" and now it states "Unclassifiable OpenACC directive". I applied this patch to gomp-4_0-branch. Cesar 2015-06-12 Cesar Philippidis gcc/c-family/ * c-omp.c (oacc_extract_device_id): Recognize GOMP_DEVI

[gomp4] OpenACC gang clause static argument

. Combined parallel loops weren't passing gang_expr, gang_static, worker_expr and vector_expr to the loop handler. This fixes that. This patch has been committed to gomp-4_0-branch. Cesar 2015-06-11 Cesar Philippidis gcc/fortran/ * trans-openmp.c (gfc_trans_omp_clauses): Handle the stat

[gomp4] filter out unrecognized device_type targets

n 6.1. In the meantime, I've applied this patch to gomp-4_0-branch. Cesar 2015-06-10 Cesar Philippidis gcc/ * c-family/c-omp.c (oacc_filter_device_types): Filter out device_type clauses even when the device_type isn't recognized. gcc/testsuite * c-c++-common/goacc/dtype-3.c:

Re: [gomp4, fortran] Patch to fix continuation checks of OpenACC and OpenMP directives

On 06/07/2015 02:05 PM, Ilmir Usmanov wrote: > Fixed fortran mail-list address. Sorry for inconvenience. > > 08.06.2015, 00:01, "Ilmir Usmanov" : >>> Hi Cesar! >>> >>> This patch fixes checks of OpenMP and OpenACC continuations in >>> case if someone mixes them (i.e. continues OpenMP directive wi

[patch] openacc vector variable broadcasting

' from shared memory sequence. As a consequence, the value being spilled is clobbered by all of the threads, not just the worker with tid=0. I applied this patch to gomp-4_0-branch. Cesar 2015-06-03 Cesar Philippidis gcc/ * builtins.c (expand_builtin_oacc_thread_broadcast): All

[ping] Re: [patch,gomp4] error on invalid acc loop clauses

Any thoughts? Maybe I should just apply this patch to gomp-4_0-branch since it doesn't introduce any regressions. On 05/20/2015 04:26 PM, Cesar Philippidis wrote: > On 05/20/2015 07:32 AM, Jakub Jelinek wrote: > >> For OpenMP/OpenACC, there is still lots of diagnosti

Re: [gomp4] Worker-single predication

On 06/01/2015 08:58 AM, Bernd Schmidt wrote: > This extends the previous vector-single support to also handle > worker-level predication. We can't use the shfl insn because workers > will live across multiple warps, so we use a location in memory to > broadcast the branch target. > This also fixes

Re: [patch,gomp4] error on invalid acc loop clauses

, that makes sense. I didn't touch the fortran front end, but I did revert most of my c and c++ front end changes in gomp-4_0-branch to defer all of the common error checking to the omp lowering phase. Is this patch ok for gomp-4_0-branch? Cesar 2015-05-20 Cesar Philippidis gcc/c/ * c-

Re: [patch,gomp4] error on invalid acc loop clauses

On 05/20/2015 01:23 AM, Thomas Schwinge wrote: >> I included two new test cases in this patch. They are mostly identical >> but, unfortunately, the c and c++ front ends emit slightly different >> error messages. > > The preference is to keep these as single files (so that C and C++ can > easily b

[patch,gomp4] remove gwv test case

er issue of variable broadcasting. As a result, this test case isn't necessary going forward. Those thread functions are already being exercised by omp-low for each acc loop anyway. Cesar 2015-05-18 Cesar Philippidis libgomp/ * testsuite/libgomp.oacc-c/gwv.c: Delete. diff --git a/libgomp/tests

[patch,gomp4] error on invalid acc loop clauses

cases in this patch. They are mostly identical but, unfortunately, the c and c++ front ends emit slightly different error messages. The front ends still need to be cleaned before this functionality should be considered for mainline. So for the time being I've applied this patch to gomp-4

[patch,gomp4] acc exit data bug fix

rly. So in the process of fixing the memory corruption bug, I fixed that issue too. I've applied this patch to gomp-4_0-branch. Cesar 2015-05-14 Cesar Philippidis libgomp/ * oacc-mem.c (gomp_acc_remove_pointer): Fix a memory leak preventing target_mem_desc.to_free from being deallocat

Re: Next set of OpenACC changes: C family

On 05/05/2015 07:18 AM, Jakub Jelinek wrote: > On Tue, May 05, 2015 at 10:57:28AM +0200, Thomas Schwinge wrote: >> --- gcc/c-family/c-common.c >> +++ gcc/c-family/c-common.c >> @@ -809,7 +809,7 @@ const struct attribute_spec c_common_attribute_table[] = >>handle_omp_decl

Re: [Patch, Fortran] PR64726 Fix OpenACC's "parallel/kernel loop"

On 01/22/2015 12:08 PM, Tobias Burnus wrote: > "parallel/kernel loop" is handled by the function being patched (an > assert ensures that no other directives end here). The first part of the > function handles the parallel and kernel part, the loop itself should be > handled by the called function.

[gomp4] fix a fortran bootstrap failure

s patch to gomp-4_0-branch. Cesar 2014-11-20 Cesar Philippidis gcc/fortran/ * openmp.c (resolve_oacc_cache): Mark the code parameter as unused. Index: gcc/fortran/openmp.c === --- gcc/fortran/openmp.c (revision 442301)

Re: [PATCH 1/5] OpenACC 2.0 support for libgomp - OpenACC runtime, NVidia PTX/CUDA plugin (repost)

On 11/19/2014 11:44 AM, Bernd Schmidt wrote: > I'm attaching the patch in the form in which I've made it work locally, > plus Cesar's patch which is needed on top of it. Julian, you'll probably > want to look for that patch since it also included testsuite changes. > Cesar - have a look over this

Re: [PATCH, libgfortran] PR 60324 Unbounded stack allocations in libgfortran

On 11/14/2014 10:01 PM, Janne Blomqvist wrote: > On Fri, Nov 14, 2014 at 11:02 PM, Tobias Burnus wrote: >> Cesar Philippidis wrote: >>> >>> On 11/13/2014 02:32 AM, Janne Blomqvist wrote: >>> I hit an error when building intrinsics/random.c: >>>

Re: [PATCH, libgfortran] PR 60324 Unbounded stack allocations in libgfortran

in C, so I've replaced the _Static_assert with a regular assert. Are you using g++ to build libgfortran? I don't have a good baseline test this patch thoroughly, but at least I can bootstrap gcc without it failing in libgfortran. Is this OK for mainline and/or could someone see if it causes any

Re: The nvptx port

On 11/14/2014 08:18 AM, Jakub Jelinek wrote: >> Also, keep in mind that PTX doesn't have a global TID. The user needs to >> calculate it using ctaid/tid and friends. > > Ok. Is %gridid needed for that combo too? Eventually, probably. Currently, we're launching all of our kernels with cuLaunchKe

Re: The nvptx port

On 11/14/2014 04:12 AM, Bernd Schmidt wrote: - we'll need some synchronization primitives, I see atomic support is there, we need mutexes and semaphores I think, is that implementable using bar instruction? >>> >>> It's probably membar you need. >> >> That

Re: [patch] OpenACC fortran front end

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

Re: [patch] OpenACC fortran front end

On 11/13/2014 08:43 AM, Jakub Jelinek wrote: > On Thu, Nov 06, 2014 at 02:25:52PM -0800, Cesar Philippidis wrote: >> * cpp.c (cpp_define_builtins): Conditionally define _OPENACC. >> * dump-parse-tree.c >> (show_omp_node): Dump also OpenACC executable

Re: OpenACC middle end changes

On 11/13/2014 11:09 AM, Jakub Jelinek wrote: > On Thu, Nov 13, 2014 at 11:03:47AM -0800, Cesar Philippidis wrote: >>>> @@ -233,6 +242,90 @@ static tree scan_omp_1_op (tree *, int *, void *); >>>>*handled_ops_p = false; \ >>>>break; >

Re: Re: OpenACC middle end changes

I'll try to respond to the reduction stuff. It's been a while since I started working on it, so I may have lost some state. On 11/13/2014 10:09 AM, Jakub Jelinek wrote: >> @@ -233,6 +242,90 @@ static tree scan_omp_1_op (tree *, int *, void *); >>*handled_ops_p = false; \ >>break;

[gomp4] fix omp_clause_code_name

debug_tree was throwing an ICE when I was debugging scan_sharing_clauses in omp-low.c. The problem turned out to be a missing comma. I've applied this fix to gomp-4_0-branch. Cesar 2014-11-12 Cesar Philippidis gcc/ * tree.c (omp_clause_code_name): Add missing comma after "_Cilk_

Re: [patch] OpenACC fortran front end

On 11/11/2014 08:51 AM, Jakub Jelinek wrote: >> We've been preparing new patches against trunk for the libgomp and >> middle-end bits: I've now posted the former, and the latter are on >> their way soon, I believe. The middle-end bits are also present on the >> gomp-4_0-branch SVN branch (likewise

Re: [patch] OpenACC fortran front end

On 11/10/2014 02:08 PM, Tobias Burnus wrote: > Cesar Philippidis wrote: >> This patch adds support for OpenACC 2.0a, with some omissions, to the >> fortran front end. It only contains the fortran changes from >> gomp-4_0-branch, therefore the middle end and runtime chang

[patch] OpenACC fortran tests

Cesar Philippidis Thomas Schwinge Ilmir Usmanov gcc/testsuite/ * gfortran.dg/goacc/acc_on_device-1.f95: New test. * gfortran.dg/goacc/acc_on_device-2-off.f95: New test. * gfortran.dg/goacc/acc_on_device-2.f95: New test. * gfortran.dg/goacc/assumed.f95: New test. * gfortran.dg

[patch] OpenACC fortran front end

front end. Am I missing any other authors in the ChangeLog? Thanks, Cesar 2014-11-06 Cesar Philippidis Thomas Schwinge Ilmir Usmanov gcc/fortran/ * cpp.c (cpp_define_builtins): Conditionally define _OPENACC. * dump-parse-tree.c (show_omp_node): Dump also OpenACC execut

Re: [patch,gomp-4_0-branch] acc nested function support

changes are OK, should I commit this change to gomp-4_0-branch, or do you want to include this patch with your middle end trunk submission? Thanks, Cesar 2014-11-04 Cesar Philippidis gcc/ * doc/gimple.texi (gimple class hierarchy): Add gimple_statement_omp_targetreg, gimple_statement_o

[gomp4] acc reductions with multiple variables

se. Cesar 2014-10-31 Cesar Philippidis Thomas Schwinge gcc/ * oacc-builtins.def (BUILT_IN_GOACC_GET_NUM_THREADS): New built-in function. (BUILT_IN_ACC_GET_DEVICE_TYPE): Likewise. * omp-low.c (oacc_max_threads): New function. (lower_reduction_clauses): Use the GOACC thread builtin

Re: [gomp4] OpenACC wait directive

On 10/06/2014 03:56 AM, Ilmir Usmanov wrote: > Otherwise, Fortran part looks good for me. Thanks for the review again! I applied this patch to gomp-4_0-branch now that the middle end pieces are in place. Thanks, Cesar 2014-10-31 Cesar Philippidis gcc/fortran/ * gfortran.h (str

[gomp4] acc enter/exit data

rs. I suspect a similar argument can be used for 2 which is only used for pointers (really subarrays): (1) data, and (2) pointer. Thomas has already approved this patch internally, so I'll commit it to gomp-4_0-branch in the next few days unless someone complains. Thanks, Cesar 2014-10-30 Cesar P

Re: [gomp4] c++ delete clause

On 10/20/2014 01:26 PM, Cesar Philippidis wrote: > On 10/20/2014 01:18 PM, Jakub Jelinek wrote: >> See how private or for clauses are handled earlier, you should >> not need to parse identifier to handle RID_DELETE as >> PRAGMA_OACC_CLAUSE_DELETE. > > I forgot about p

[gomp4] acc self/host/device clauses

committing this patch until the wait patch goes in. It this OK for gomp-4_0-branch? Thanks, Cesar 2014-10-20 Cesar Philippidis gcc/fortran/ * gfortran.h (enum OMP_LIST_HOST): Remove. (enum OMP_LIST_DEVICE): Remove. * dump-parse-tree.c (show_omp_clauses): Remove OMP_LIST_HOST and OMP_L

[gomp4] acc dealloc map

All of the various OpenACC memory maps are now fully supported in GCC. This patch removes an obsolete sorry message complaining about DEALLOCATE maps not being implemented. I've committed this to gomp-4_0-branch. Cesar 2014-10-20 Cesar Philippidis gcc/ * gimpl

Re: [gomp4] c++ delete clause

On 10/20/2014 01:18 PM, Jakub Jelinek wrote: > On Mon, Oct 20, 2014 at 01:12:08PM -0700, Cesar Philippidis wrote: >> The OpenACC delete clause isn't detected in the c++ front end because >> the lexer classifies it as a keyword, which it is. This patch makes the >> open

[gomp4] acc update bug

ll be provided later. Cesar 2014-10-20 Cesar Philippidis gcc/c/ * c-parser.c (c_parser_oacc_update): Don't create a new stmt if the pragma is bogus. libgomp/ * (GOACC_update): Declare. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 17085bf..d1956b8 100644 --- a/gcc/c/c-parser.c

[gomp4] c++ delete clause

upport for the acc enter/exit data directive. Cesar 2014-10-20 Cesar Philippidis gcc/cp/ * parser.c (cp_parser_omp_clause_name): Also consider CPP_KEYWORD typed tokens as clauses for delete. diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 8fd470a..19cbf37 100644 --- a/gcc/cp/parser.c

Re: [gomp4] reduction bug fix

On 10/08/2014 02:38 AM, Thomas Schwinge wrote: > On Fri, 3 Oct 2014 09:22:52 -0700, Cesar Philippidis > wrote: >> There is a reduction bug [...] > > Thanks for looking into this! > >> This is a problem because initialize_reduction_data originally expected &

Re: [gomp4] OpenACC wait directive

ction after whole > program. > So, since you are resolving wait-list during match, you don't cover this > case. But async clause works fine. I moved that check back into resolve_omp_clauses. So it functions now. > By the way, the same difference between wait and async presents in C

Re: [gomp4] OpenACC wait directive

On 10/03/2014 07:34 AM, Cesar Philippidis wrote: > On 09/24/2014 12:18 AM, Ilmir Usmanov wrote: >> Hi Cesar! >> >> Thank you for the patch! >> >> On 24.09.2014 02:29, Cesar Philippidis wrote: >>> This patch adds support for the async clause in the wait dir

[gomp4] reduction bug fix

ome typos in the original comment, so I took the opportunity to fix them, I hope. Is this OK for gomp-4_0-branch? Thanks, Cesar 2014-10-02 Cesar Philippidis gcc/ * omp-low.c (lower_reduction_clauses): Clarify comment. (process_reduction_data): Scan for nonempty bind statements at the begin

Re: [gomp4] OpenACC wait directive

On 09/24/2014 12:18 AM, Ilmir Usmanov wrote: > Hi Cesar! > > Thank you for the patch! > > On 24.09.2014 02:29, Cesar Philippidis wrote: >> This patch adds support for the async clause in the wait directive in >> fortran. It should be pretty straight forward. The for

[gomp4] OpenACC wait directive

gomp-4_0-branch? Note that this patch doesn't actually implement the async or wait clause in the middle end yet, because that requires additional runtime support. Thanks, Cesar 2014-09-23 Cesar Philippidis gcc/fortran/ * openmp.c (OACC_WAIT_CLAUSES): New mask. (gfc_match_oacc_wait): U

Re: [gomp4] various OpenACC/PTX built-ins and a reduction tweak

On 09/18/2014 11:43 AM, Thomas Schwinge wrote: > Hi Cesar! > > On Tue, 16 Sep 2014 17:32:54 -0700, Cesar Philippidis > wrote: >> The patch introduces the following OpenACC/PTX-specific built-ins: >> >> * GOACC_ntid >> * GOACC_tid >> * GOACC_ncta

Re: [gomp4] various OpenACC/PTX built-ins and a reduction tweak

On 09/17/2014 01:49 AM, Jakub Jelinek wrote: > On Wed, Sep 17, 2014 at 10:44:12AM +0200, Tobias Burnus wrote: >> Cesar Philippidis wrote: >>> The patch introduces the following OpenACC/PTX-specific built-ins: >> ... >> >> It is not completely clear how they

[gomp4] various OpenACC/PTX built-ins and a reduction tweak

ause recently. Is this OK for gomp-4_0-branch? Thanks, Cesar 2014-09-16 Cesar Philippidis gcc/ * builtins.c (expand_builtin_acc_on_device): New function. (expand_oacc_builtin): New function. (expand_builtin): Handle BUILT_IN_GOACC_NCTAID, BUILT_IN_GOACC_CTAID, BUILT_IN_

[gomp4] OpenACC routine directive

that fortran lacks a file scope, so 'acc routine' wouldn't be visible to fact. Is this patch OK for gomp-4_0-branch? Thanks, Cesar 2014-09-15 Cesar Philippidis gcc/c-family/ * c-pragma.c (oacc_pragmas): Add the "routine" pragma. * c-pragma.h (pragma_

Re: [patch,gomp4] make fortran loop variables implicitly private in openacc

On 09/07/2014 11:26 PM, Tobias Burnus wrote: > sorry for the slow review. No problem. I've been focusing on the subroutine clause lately. > On 22 August 2014 17:08, Cesar Philippidis wrote: >>> In OpenMP, one has (OMP 4.0, 2.14.3): "A list item that specifies a >>

Re: [patch,gomp4] make fortran loop variables implicitly private in openacc

On 08/13/2014 01:41 PM, Tobias Burnus wrote: > Cesar Philippidis wrote: >> According to section 2.6.1 in the openacc spec, fortran loop variables >> should be implicitly private like in openmp. This patch does just so. > > Makes sense. Looking at the patch, I wonder w

Re: [patch,gomp4] make fortran loop variables implicitly private in openacc

On 08/11/2014 04:55 PM, Cesar Philippidis wrote: > According to section 2.6.1 in the openacc spec, fortran loop variables > should be implicitly private like in openmp. This patch does just so. > Also, while working on this patch, I noticed that I made the check for > variables

[patch,gomp4] make fortran loop variables implicitly private in openacc

also appear inside a reduction clause. I've also included a fix for this in this patch. Is this OK for gomp-4_0-branch? Thanks, Cesar 2014-08-11 Cesar Philippidis gcc/fortran/ * openmp.c (oacc_compatible_clauses): New function. (resolve_omp_clauses): Use it. (oacc_current_ctx): Move it

Re: [PATCH] [gomp4] Initial support of OpenACC loop directive in C front-end.

On 07/29/2014 02:07 AM, Thomas Schwinge wrote: > On Thu, 20 Mar 2014 15:42:48 +0100, I wrote: >> On Tue, 18 Mar 2014 14:50:44 +0100, I wrote: >>> On Tue, 18 Mar 2014 16:37:24 +0400, Ilmir Usmanov >>> wrote: This patch introduces support of OpenACC loop directive (and combined directiv

Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

On 08/01/2014 12:48 AM, Jakub Jelinek wrote: > On Wed, Jul 23, 2014 at 05:42:32PM -0700, Cesar Philippidis wrote: >>>> Jakub, before your Fortran OpenMP 4 target changes, Ilmir had written the >>>> test case gcc/testsuite/gfortran.dg/gomp/map-1.f90 (based on

Re: [patch,gomp-4_0-branch] openacc parallel reduction part 1

On 07/28/2014 10:02 AM, Thomas Schwinge wrote: > Hi Cesar! > > On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis > wrote: >> This patch is the first step to enabling parallel reductions in openacc. > > I think I have found one issue in this code -- but please verify

Re: [patch,gomp-4_0-branch] reductions with reference vars

On 07/28/2014 09:27 AM, Thomas Schwinge wrote: > On Mon, 28 Jul 2014 07:26:30 -0700, Cesar Philippidis > wrote: >> After testing the reduction clause inside fortran subroutines, I noticed >> that I wasn't handling reference variables properly. This patch fixes >>

Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

On 07/25/2014 09:01 AM, Thomas Schwinge wrote: > On Thu, 24 Jul 2014 15:44:13 -0700, Cesar Philippidis > wrote: >> On 07/24/2014 06:11 AM, Thomas Schwinge wrote: >>> I'd suggest to continue to handle all the data clauses [...] >> >> I moved a

[patch,gomp-4_0-branch] reductions with reference vars

Hi Thomas, After testing the reduction clause inside fortran subroutines, I noticed that I wasn't handling reference variables properly. This patch fixes that. Is this OK for gomp-4_0-branch? Thanks, Cesar 2014-07-24 Cesar Philippidis gcc/ * omp-low.c (get_base_type): New fun

Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

the only conflicting one?) I moved all of the data clause matching back to gfc_match_omp_clauses, and I guarded the copyin clause with the openacc flag. It looks like the private clause may also require a special memory mapping, so I left the openacc flag in place. >>

Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

xfail *-*-* } } >> + >> + !$omp target map(tt%j(1:)) ! { dg-bogus "Syntax error in OpenMP variable >> list" "" { xfail *-*-* } } >> + !$omp end target ! { dg-bogus "Unexpected !\\\$OMP END TARGET statement" >> "" { xfail *-*-

[patch,gomp-4_0-branch] acc nested function support

tions. Does this look OK to commit to gomp-4_0-branch? Thanks, Cesar 2014-07-17 Cesar Philippidis gcc/ * gcc/gimple.h (gimple_statement_oacc_kernels, gimple_statment_oacc_parallel): Derive from gimple_statement_omp_taskreg instestead of gimple_statement_omp_parallel_layout. (is_a_h

Re: [patch,gomp-4_0-branch] openacc collapse clause

On 07/11/2014 02:27 AM, Thomas Schwinge wrote: > Hi Cesar! > > On Thu, 10 Jul 2014 11:47:42 -0700, Cesar Philippidis > wrote: >> These patch enables the collapse clause with a value greater than one. > > Thanks! > >> Is this patch OK for gomp-4_0-branch? >

Re: [patch,gomp-4_0-branch] misc reduction clause bug fixes

On 07/11/2014 02:15 AM, Thomas Schwinge wrote: > Hi Cesar! > > On Thu, 10 Jul 2014 11:43:11 -0700, Cesar Philippidis > wrote: >> This patch addresses two bugs openacc reduction clause bugs. > > Thanks! OK; one question/suggestion, though: > >> --- a/gcc

[patch,gomp-4_0-branch] openacc collapse clause

Hi Thomas, These patch enables the collapse clause with a value greater than one. We had partial support for the collapse clause which supported a value of 1, because the fortran frontend always associated a collapse clause with each openacc for loop. However in terms of actual collapse support, a

[patch,gomp-4_0-branch] misc reduction clause bug fixes

Hi Thomas, This patch addresses two bugs openacc reduction clause bugs. The first bug occurred because I didn't anticipate a GIMPLE_BIND stmt to be passed to process_reduction_data. Turns out, this could happen with the collapse clause. That's because the variables which were declared inside the i

Re: [patch,gomp-4_0-branch] openacc parallel reduction part 1

On 07/08/2014 07:28 AM, Cesar Philippidis wrote: > Thanks for catching those problems! I've committed this updated version > of the patch. I forgot to remove the support for the collapse clause in from the loop construct in the c frontend. I did so upstream, but not internally. I&#x

Re: [patch,gomp-4_0-branch] openacc parallel reduction part 1

On 07/07/2014 02:55 AM, Thomas Schwinge wrote: > On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis > wrote: >> This patch is the first step to enabling parallel reductions in openacc. > > Thanks! > >> As mentioned earlier, this patch isn't complete yet. For

Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse

On 07/08/2014 02:21 AM, Tobias Burnus wrote: > Cesar Philippidis wrote: >> Thomas, is this OK for gomp-4_0-branch? > ... > > >> * gcc/fortran/scanner.c (gfc_next_char_literal): Fix the scan for >> *$acc. > > This changes looks good to me. >

Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse

couple of typos in scanner which caused gfc_next_char and friends to fail when handling fixed-form comments. There was also something being handled strangely in the parser, when I went ahead and fixed. I think there may be a few more bugs lurking in the fixed-form comment handling. Thomas, is t

[patch,gomp-4_0-branch] openacc parallel reduction part 1

is this patch OK for gomp-4_0-branch? Thanks, Cesar 2014-07-06 Cesar Philippidis Thomas Schwinge gcc/ * omp-low.c (omp_get_id): New function. (lookup_reduction): New function. (maybe_lookup_reduction): New function. (build_outer_var_ref): Remove openacc assert.

Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse

On 07/03/2014 10:01 AM, Thomas Schwinge wrote: > I'm happy to, but why don't we just get you set up? You're covered by > the general Mentor Graphics/CodeSourcery copyright assignment. Please > request an account per , and on >

Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse

uot; or "*" in this case and not > "$". In addition, also in this case, one might want to set the other > flag to 0. > > > My feeling is that the bug is also related to something in scanner.c. The problem was inside skip_fixed_comments. The openacc_flag wasn't

Re: [patch][gomp4] openacc loops

t;op == EXEC_DO_CONCURRENT) >> +gfc_error ("!$ACC LOOP directive is unsupported on DO CONCURRENT >> %L", >> + &code->loc); >> gcc_assert (code->op == EXEC_DO); >> >> init = make_tree_vec (collapse); >> cond = make_tree_vec

Re: [patch][gomp4] openacc loops

On 06/04/2014 12:49 PM, Thomas Schwinge wrote: (Note that I split up the original patches into two components. This is the omp-low.c component.) > On Tue, 3 Jun 2014 16:00:30 -0700, Cesar Philippidis > wrote: >> in order to make >> the patch yield more interesting results,

[patch][gomp4] openacc loops

ng to be handled inside libgomp or by the compiler? Eg, consider a subroutine which takes in to allocatable arrays as parameters, a and b. What happens when a == b? We don't want to have two different copies of whatever a and b point to on the target. Thanks, Cesar 2014-06-03 Ilmir Usmanov

Re: [patch ping] libstdc++ testsuite cxxflags

On 05/20/2014 02:11 AM, Jonathan Wakely wrote: > On 19/05/14 14:57 -0600, Sandra Loosemore wrote: >> On 05/17/2014 04:07 AM, Jonathan Wakely wrote: >>> On 17 May 2014 10:50, Jonathan Wakely wrote: On 17 May 2014 01:16, Sandra Loosemore wrote: > It appears that this patch from last fall nev

[patch] fix ppc spe bootstrap error in dwf_regno

er for this application. Is this patch ok for trunk and 4.9? If so, please commit since I don't have an svn account. Cesar 2014-04-30 Cesar Philippidis gcc/ * dwarf2cfi.c (dwf_regno): Don't assert reg is a pseudo register. diff --git a/gcc/dwarf2cfi.c b/

Re: [patch] make -flto -save-temps less verbose

On 3/13/14, 2:52 AM, Richard Biener wrote: > On Thu, Mar 13, 2014 at 10:31 AM, Richard Biener > wrote: >> On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis >> wrote: >>> I noticed that the lto-wrapper is a little noisy without the -v option >>> when -sav

[patch] make -flto -save-temps less verbose

27;ve also included a simple test case which would fail without the change. Is this OK for stage-4? If so, please check it in since I don't have an SVN account. Thanks, Cesar 2014-03-12 Cesar Philippidis gcc/ * lto-wrapper.c (maybe_unlink_file): Suppress diagnostic

Re: [patch] combine ICE fix

On 10/16/13, 11:03 AM, Jeff Law wrote: > On 10/16/13 09:34, Cesar Philippidis wrote: >> On 10/15/13 12:16 PM, Jeff Law wrote: >>> On 10/10/13 10:25, Jakub Jelinek wrote: >>>> On Thu, Oct 10, 2013 at 07:26:43AM -0700, Cesar Philippidis wrote: >>>>> This

<    1   2   3   4   5   6   7   >