On 07/28/2015 02:21 AM, Thomas Schwinge wrote:
Cesar, please address the following compiler diagnostig:
2015-07-21 Cesar Philippidis ce...@codesourcery.com
gcc/
* omp-low.c (execute_oacc_transform): New function.
(class pass_oacc_transform): New function
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 now.
Cesar
2015-07-24 Cesar Philippidis ce
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 patch does just that; it teaches
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
fine because not all targets can handle
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's kind of messy though
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-linux-gnu.
Cesar
2015-07-22 Cesar Philippidis ce...@codesourcery.com
Tom de Vries vr
calls using target machine hooks. This
pass will run after lto on the target compiler.
Thanks,
Cesar
2015-07-21 Cesar Philippidis ce...@codesourcery.com
gcc/
* omp-low.c (execute_oacc_transform): New function.
(class pass_oacc_transform): New function.
(make_pass_oacc_transform): New function
-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 ce...@codesourcery.com
gcc/
* config/nvptx/nvptx.c (nvptx_generate_vector_shuffle): New function.
(nvptx_goacc_fold_reduction
-17 Cesar Philippidis ce...@codesourcery.com
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
it 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 ce...@codesourcery.com
libgomp/
* testsuite/libgomp.oacc-c-c++-common/reduction.h: New file.
* testsuite/libgomp.oacc-c-c
, Cesar Philippidis ce...@codesourcery.com:
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 m...@ilmir.us:
Hi Cesar!
This patch fixes checks of OpenMP and OpenACC continuations in
case
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 ce...@codesourcery.com
gcc/
* omp-low.c (oacc_get_reduction_array_id): Remove
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
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,
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
+++
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 Philippidis
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 ce...@codesourcery.com
gcc/
* omp-low.c
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 ce...@codesourcery.com
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 ce...@codesourcery.com
gcc/c-family/
* c-omp.c (oacc_extract_device_id): Recognize GOMP_DEVICE_DEFAULT
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 ce...@codesourcery.com
gcc/fortran/
* trans-openmp.c (gfc_trans_omp_clauses): Handle
. In the meantime, I've applied this patch to
gomp-4_0-branch.
Cesar
2015-06-10 Cesar Philippidis ce...@codesourcery.com
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
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 m...@ilmir.us:
Hi Cesar!
This patch fixes checks of OpenMP and OpenACC continuations in
case if someone mixes them (i.e. continues OpenMP directive with
. 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 ce...@codesourcery.com
gcc/
* builtins.c (expand_builtin_oacc_thread_broadcast): Allow
constant value operads
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 the
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 diagnostics emitted during
gimplification
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 be
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 ce...@codesourcery.com
gcc/c/
* c
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 ce...@codesourcery.com
libgomp/
* testsuite/libgomp.oacc-c/gwv.c: Delete.
diff --git a/libgomp/testsuite
. 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_0-branch.
Cesar
2015-05-15 Cesar
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 ce...@codesourcery.com
libgomp/
* oacc-mem.c (gomp_acc_remove_pointer): Fix a memory leak preventing
target_mem_desc.to_free from being deallocated with acc
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[] =
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.
-4_0-branch.
Cesar
2014-11-20 Cesar Philippidis ce...@codesourcery.com
gcc/fortran/
* openmp.c (resolve_oacc_cache): Mark the code parameter
as unused.
Index: gcc/fortran/openmp.c
===
--- gcc/fortran/openmp.c (revision 442301
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
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 is a memory barrier, I need
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
cuLaunchKernel,
. 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 regressions?
Thanks,
Cesar
2014-11-14 Cesar Philippidis ce
On 11/14/2014 10:01 PM, Janne Blomqvist wrote:
On Fri, Nov 14, 2014 at 11:02 PM, Tobias Burnus bur...@net-b.de wrote:
Cesar Philippidis wrote:
On 11/13/2014 02:32 AM, Janne Blomqvist wrote:
I hit an error when building intrinsics/random.c:
error: expression in static assertion
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;
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;
+/* Helper function to get the reduction array name
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 statements.
Put (show_omp_node
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 them.
Use your @gcc.gnu.org account
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 ce...@codesourcery.com
gcc/
* tree.c (omp_clause_code_name): Add missing comma
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, the
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 changes are a
necessary prerequisite
missing any other authors in the ChangeLog?
Thanks,
Cesar
2014-11-06 Cesar Philippidis ce...@codesourcery.com
Thomas Schwinge tho...@codesourcery.com
Ilmir Usmanov i.usma...@samsung.com
gcc/fortran/
* cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
* dump-parse-tree.c
Cesar Philippidis ce...@codesourcery.com
Thomas Schwinge tho...@codesourcery.com
Ilmir Usmanov i.usma...@samsung.com
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
, 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 ce...@codesourcery.com
gcc/
* doc/gimple.texi (gimple class hierarchy): Add
gimple_statement_omp_targetreg
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 ce...@codesourcery.com
gcc/fortran
2014-10-31 Cesar Philippidis ce...@codesourcery.com
Thomas Schwinge tho...@codesourcery.com
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
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 Philippidis ce
for the acc enter/exit
data directive.
Cesar
2014-10-20 Cesar Philippidis ce...@codesourcery.com
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
will be
provided later.
Cesar
2014-10-20 Cesar Philippidis ce...@codesourcery.com
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
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
openacc pragma parser aware
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 ce...@codesourcery.com
gcc/
* gimplify.c
this patch until the wait patch goes in.
It this OK for gomp-4_0-branch?
Thanks,
Cesar
2014-10-20 Cesar Philippidis ce...@codesourcery.com
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
On 10/08/2014 02:38 AM, Thomas Schwinge wrote:
On Fri, 3 Oct 2014 09:22:52 -0700, Cesar Philippidis ce...@codesourcery.com
wrote:
There is a reduction bug [...]
Thanks for looking into this!
This is a problem because initialize_reduction_data originally expected
a GIMPLE_BIND
into resolve_omp_clauses. So it functions now.
By the way, the same difference between wait and async presents in CFE.
Otherwise, Fortran part looks good for me.
Thomas, any thoughts on the CFE?
Thanks,
Cesar
2014-10-06 Cesar Philippidis ce...@codesourcery.com
James Norris jnor
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 directive in
fortran. It should be pretty straight forward
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 fortran FE already
supports the wait
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 ce...@codesourcery.com
gcc/
* omp-low.c (lower_reduction_clauses): Clarify comment.
(process_reduction_data): Scan for nonempty bind statements
for 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 ce...@codesourcery.com
gcc/fortran/
* openmp.c (OACC_WAIT_CLAUSES): New mask
On 09/18/2014 11:43 AM, Thomas Schwinge wrote:
Hi Cesar!
On Tue, 16 Sep 2014 17:32:54 -0700, Cesar Philippidis
ce...@codesourcery.com wrote:
The patch introduces the following OpenACC/PTX-specific built-ins:
* GOACC_ntid
* GOACC_tid
* GOACC_nctaid
* GOACC_ctaid
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 are supposed to get used. Should the
user call them
for gomp-4_0-branch?
Thanks,
Cesar
2014-09-16 Cesar Philippidis ce...@codesourcery.com
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_GOACC_NTID
.
Is this patch OK for gomp-4_0-branch?
Thanks,
Cesar
2014-09-15 Cesar Philippidis ce...@codesourcery.com
gcc/c-family/
* c-pragma.c (oacc_pragmas): Add the routine pragma.
* c-pragma.h (pragma_kind): Add PRAGMA_OACC_ROUTINE.
gcc/c/
* c-parser.c (struct c_parser): New oacc_routines member
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
given variable may not appear in more
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 whether the context is
properly
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 appearing in multiple
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 ce...@codesourcery.com
gcc/fortran/
* openmp.c (oacc_compatible_clauses): New function.
(resolve_omp_clauses): Use
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 i.usma...@samsung.com
wrote:
This patch introduces support of OpenACC loop directive (and combined
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 his
interpretation and implementation of OpenMP
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 ce...@codesourcery.com
gcc/
* omp-low.c (get_base_type
On 07/25/2014 09:01 AM, Thomas Schwinge wrote:
On Thu, 24 Jul 2014 15:44:13 -0700, Cesar Philippidis
ce...@codesourcery.com wrote:
On 07/24/2014 06:11 AM, Thomas Schwinge wrote:
I'd suggest to continue to handle all the data clauses [...]
I moved all of the data clause matching back
On 07/28/2014 09:27 AM, Thomas Schwinge wrote:
On Mon, 28 Jul 2014 07:26:30 -0700, Cesar Philippidis
ce...@codesourcery.com wrote:
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
On 07/28/2014 10:02 AM, Thomas Schwinge wrote:
Hi Cesar!
On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis
cesar_philippi...@mentor.com 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
2014-07-24 Cesar Philippidis ce...@codesourcery.com
gcc/fortran/
* gfortran.h (gfc_omp_map_op): Add OMP_MAP_FORCE_ALLOC,
OMP_MAP_FORCE_DEALLOC, OMP_MAP_FORCE_TO, OMP_MAP_FORCE_FROM,
OMP_MAP_FORCE_TOFROM, OMP_MAP_FORCE_PRESENT.
(enum) Remove OMP_LIST_OACC_COPYIN, OMP_LIST_COPYOUT
:] and similar is explicitly invalid.
Jakub, should I drop the map-1.f90 test?
Thanks,
Cesar
2014-07-23 Cesar Philippidis ce...@codesourcery.com
Thomas Schwinge tho...@codesourcery.com
Ilmir Usmanov i.usma...@samsung.com
gcc/fortran/
* gfortran.h (gfc_omp_map_op): Add OMP_MAP_TOFROM
.
Does this look OK to commit to gomp-4_0-branch?
Thanks,
Cesar
2014-07-17 Cesar Philippidis ce...@codesourcery.com
gcc/
* gcc/gimple.h (gimple_statement_oacc_kernels,
gimple_statment_oacc_parallel): Derive from
gimple_statement_omp_taskreg instestead
On 07/11/2014 02:15 AM, Thomas Schwinge wrote:
Hi Cesar!
On Thu, 10 Jul 2014 11:43:11 -0700, Cesar Philippidis
ce...@codesourcery.com wrote:
This patch addresses two bugs openacc reduction clause bugs.
Thanks! OK; one question/suggestion, though:
--- a/gcc/omp-low.c
+++ b/gcc/omp
On 07/11/2014 02:27 AM, Thomas Schwinge wrote:
Hi Cesar!
On Thu, 10 Jul 2014 11:47:42 -0700, Cesar Philippidis
ce...@codesourcery.com wrote:
These patch enables the collapse clause with a value greater than one.
Thanks!
Is this patch OK for gomp-4_0-branch?
OK with the following
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
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,
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.
* parse.c (next_fixed): Don't handle openmp
On 07/07/2014 02:55 AM, Thomas Schwinge wrote:
On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis
cesar_philippi...@mentor.com wrote:
This patch is the first step to enabling parallel reductions in openacc.
Thanks!
As mentioned earlier, this patch isn't complete yet. For starters
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've
checked
and fixed. I think there may be a few more bugs lurking in
the fixed-form comment handling.
Thomas, is this OK for gomp-4_0-branch?
Cesar
2014-07-07 Cesar Philippidis ce...@codesourcery.com
gcc/fortran/
* parse.c (next_fixed): Don't handle openmp pragmas when scanning
for openacc pragmas
,
Cesar
2014-07-06 Cesar Philippidis ce...@codesourcery.com
Thomas Schwinge tho...@codesourcery.com
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.
(new_omp_context
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 http://gcc.gnu.org/svnwrite.html, and on
-branch? If so, please check it in.
Thanks,
Cesar
PS: I might try later to find out what goes wrong, but that requires in
any case a binary which is not older than the source code.
2014-07-02 Cesar Philippidis ce...@codesourcery.com
gcc/fortran/
* scanner.c (skip_fixed_comments): Reset
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 ce...@codesourcery.com
wrote:
in order to make
the patch yield more interesting results, I've
produces regression on parallel-tree.f95 testcase: ICE.
I've replaced the asserts with sorry messages in my other patch, so it
shouldn't ICE anymore.
If this patch is OK with you, please commit it.
Thanks,
Cesar
2014-06-04 Ilmir Usmanov i.usma...@samsung.com
Cesar Philippidis ce
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 i.usma...@samsung.com
Cesar Philippidis ce
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 never got
.
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 ce...@codesourcery.com
gcc/
* dwarf2cfi.c (dwf_regno): Don't assert reg is a pseudo
register.
diff --git a/gcc/dwarf2cfi.c b/gcc
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 ce...@codesourcery.com
gcc/
* lto-wrapper.c (maybe_unlink_file): Suppress
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 patch addresses an ICE when building qemu for a Mips target
On 11/21/13, 5:42 AM, Jonathan Wakely wrote:
On 20 November 2013 23:57, Cesar Philippidis wrote:
On 11/20/13, 1:46 PM, Jonathan Wakely wrote:
On 20 November 2013 21:44, Jonathan Wakely wrote:
On 29 October 2013 15:37, Cesar Philippidis wrote:
This patch addresses two issues with the libstdc
On 11/20/13, 1:46 PM, Jonathan Wakely wrote:
On 20 November 2013 21:44, Jonathan Wakely wrote:
On 29 October 2013 15:37, Cesar Philippidis wrote:
This patch addresses two issues with the libstdc++ testsuite:
* duplicate -g -O2 CXXFLAGS
* missing -g -O2 for remote targets
The duplicate
On 11/19/13, 1:37 AM, Marcus Shawcroft wrote:
On 18 November 2013 18:02, Cesar Philippidis ce...@codesourcery.com wrote:
gcc.c-torture/execute/20101011-1.c test on aarch64. The reason why this
test fails is because aarch64 does not trap on integer division by zero.
Is this OK for trunk
501 - 600 of 620 matches
Mail list logo
