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
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
ized 0 loops" 1
Apparently the intent of these particular tests is to ensure that those
loops do not get vectorized when the target does not support SIMD.
Is this OK for trunk? If so, please commit it since I do not have a SVN
account.
Thanks,
Cesar
2013-11-05 Cesar Philippidis
On 11/6/13, 5:06 PM, Joseph S. Myers wrote:
> You should be testing aarch64*-*-* so as to match aarch64_be targets.
Thank you for catching that. Please commit this new patch if is OK. I
don't have SVN access.
Thanks,
Cesar
2013-11-06 Cesar Philippidis
gcc/testsuite/
This patch addresses the failures caused by the
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? If so, please commit it because I do not have an
svn account.
Thanks,
Cesar
On 11/18/13, 10:01 AM, Andrew Pinski wrote:
> On Mon, Nov 18, 2013 at 9:58 AM, Cesar Philippidis
> wrote:
>> This patch addresses the failures caused by the
>> gcc.c-torture/execute/20101011-1.c test on aarch64. The reason why this
>> test fails is because aarch64
On 11/19/13, 1:37 AM, Marcus Shawcroft wrote:
> On 18 November 2013 18:02, Cesar Philippidis 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.
>>
This patch needs a review.
<http://gcc.gnu.org/ml/libstdc++/2013-10/msg00224.html>
Thanks,
Cesar
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"
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:
>>
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
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
&
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
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
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
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
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
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
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
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,
les the lastprivate clause, but that
shouldn't matter for the loop directive since it can't get set. Likewise
for the SIMD stuff.
Is there any specific reason why you created a new function to handle
openacc loops?
>> code = code->block->next;
>> + if (code-&g
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
; <https://sourceware.org/cgi-bin/pdw/ps_form.cgi> put in
> as approver.
Thank you for sponsoring me Thomas! Fixed in r212269.
Cesar
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.
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
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
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
he ones that we expect to run successfully belong in libgomp?
>> +[...]
>
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 377 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 397 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 400 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 423 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 426 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 429 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 535 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 555 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 558 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 581 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 584 }
>> +// { dg-error "OpenACC construct inside of non-OpenACC region" "" { target
>> *-*-* } 587 }
>
> Hmm, that doesn't happen for C?
I'm not sure why, unfortunately.
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/goacc/loop-1.c
>
> You didn't actually commit this file.
Two files that I missed.
>> @@ -0,0 +1,674 @@
>> +[...]
>> +// { dg-excess-errors "invalid controlling predicate" }
>
> Why is that needed?
I'm not sure. I thought it had something to do with Bernd's predication
pass.
Cesar
, 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-
add
> no predication inside this loop.
>
> Committed on gomp-4_0-branch.
Thanks. This fixed the problems that I was seeing with variables outside
of acc loops.
I see that calls are being predicated at the moment. Those will need
special handling once we tackle acc routines.
Cesar
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
' 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
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
he caller and to this switch. Perhaps pass
> omp_clause_code kind argument instead of pragma_omp_clause c_kind?
>
>> static tree
>> -c_parser_omp_clause_num_workers (c_parser *parser, tree list)
>> +c_parser_oacc_shape_clause (c_parser *parser, pragma_omp_clause c_kind,
>> +const char *str, tree list)
>> {
>> - location_t num_workers_loc = c_parser_peek_token (parser)->location;
>> - if (c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
>> + omp_clause_code kind;
>> + const char *id = "num";
>> +
>> + switch (c_kind)
>
> Likewise.
>
>> +/* Split the 'clauses' into a set of 'loop' clauses and a set of
>> + 'not-loop' clauses. */
>>
>> static tree
>> -c_parser_oacc_kernels (location_t loc, c_parser *parser, char *p_name)
>> +oacc_split_loop_clauses (tree clauses, tree *not_loop_clauses)
>
> Is this really C specific? I mean, for OpenMP I'm sharing the clause
> splitting code between C and C++ FEs in c-omp.c.
Probably not. C++ support was added late. We'll clean up this patch.
Cesar
tree nthreads, gimple_seq *stmt_seqp,
>> + omp_context *ctx)
>
> Likewise.
>
>> +/* Scan through all of the gimple stmts searching for an OMP_FOR_EXPR, and
>> + scan that for reductions. */
>> +
>> +static void
>> +process_reduction_data (gimple_seq *body, gimple_seq *in_stmt_seqp,
>> +gimple_seq *out_stmt_seqp, omp_context *ctx)
>
> Likewise.
Thomas, would you like me to handle the renaming, or will you? I could
make those changes to gomp-4_0-branch if you like.
Cesar
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;
>
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
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
amic parallelism) waits for the kernel to finish, and that
effectively creates a barrier.
PTX does have an intra-gang synchronization primitive, which is helpful
if the control flow diverges within a gang. Also, unless I'm mistaken,
the PTX atomic operations only work within a gang.
Also, keep in mind that PTX doesn't have a global TID. The user needs to
calculate it using ctaid/tid and friends.
Cesar
e what
grids corresponds to, but I think it might be devices. If that's the
case, the runtime does have the capability to select which device to run
a kernel on. But, it can't run a single kernel on multiple devices
unless you use asynchronous kernel invocations.
Cesar
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
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:
>>>
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.
&g
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)
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:
. 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
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
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
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
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
rgets, vector_length = warp_sz, which is currently 32 threads. I'll
follow up this patch with another one which adds support for tree
reductions in vector loops in a later date.
This patch has been applied to gomp-4_0-branch.
Cesar
> /* { dg-do run } */
> -/* { dg-options "-fno-inline -fno-var-tracking" } */
> +/* { dg-additional-options "-fno-inline -fno-var-tracking" } */
Is -fno-var-tracking still required? I thought Thomas fixed that a while
ago.
Cesar
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
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
t, I have an identical patch in our internal
branch and I don't know why it didn't make its way upstream or at least
into gomp-4_0-branch. Maybe it got lost after stage 1 closed. Sorry
about that.
Cesar
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
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
m and GOACC_get_num_threads to determine thread info.
Those functions are internal to libgomp. I probably should implement
them as built-ins for the ptx backend because the thread information are
exposed as registers in that target.
I'll apply this to gomp-4_0-branch next week unless says otherwi
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
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
This patch contains compile-time tests for OpenACC in gfortran. Is this
patch OK for mainline trunk after the OpenACC fortran front end changes
make their way in?
The fortran front end changes can be found here:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00553.html
Thanks,
Cesar
2014-11-06
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
same bits
> again, and worse if there are conflicts between the two patchsets, if
> both patchsets were to be approved, one couldn't be committed anyway.
Just for clarification, Julian's most recent libgomp patches are built
on top of the patches in kyukhin/gomp4-offload. He even mentions so here
<https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00986.html>.
Cesar
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_
.
Is this patch OK for trunk? I bootstrapped and regression tested it
for x86_64 Linux with nvptx offloading.
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Filter out
GOMP_MAP_STRUCT for acc exit data.
(gimplify_omp_target_update): Promote GOMP_
for attach or detach. Likewise, c_finish_omp_clauses
calls c_oacc_check_attachments to ensure that the variable is a
pointer.
Is this patch OK for trunk? I bootstrapped and regression tested it
for x86_64 Linux with nvptx offloading.
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/c/
* c
ed in the future to support more complicated C++
functionality.
Is this patch OK for trunk? I bootstrapped and regression tested it
for x86_64 Linux with nvptx offloading.
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/cp/
* parser.c (cp_parser_omp_clause_name): Scan for attach and d
This patch introduces a couple of compiler tests for the OpenACC
attach and detach clauses.
Is this OK for trunk after the other patches get approved?
Thanks,
Cesar
2018-XX-YY Cesar Philippidis
gcc/testsuite/
* c-c++-common/goacc/mdc-1.c: New test.
* c-c++-common/goacc/mdc-2.c: New test
On 10/5/18 23:22, Tom de Vries wrote:
> On 9/18/18 10:04 PM, Cesar Philippidis wrote:
>> 591973d3c3a [nvptx] use user-defined vectors when possible
>
> If I drop this patch, I get the same test results. Can you find a
> testcase for which this patch has an effect?
I just re
patch tweaks GOMP_MAP_DEEP_COPY because OG8 has a lot of
other map types for acc declare and dynamic arrays. I suspect that
change would be required for trunk too, eventually.
I've committed this patch to openacc-gcc-8-branch.
Cesar
2018-10-30 Cesar Philippidis
gcc/
*
anly. Other than
that, these patches are identical.
I've committed this patch to openacc-gcc-8-branch.
Cesar
2018-10-30 Cesar Philippidis
gcc/c/
* c-parser.c (c_parser_omp_clause_name): Scan for attach and detach.
(c_parser_oacc_data_clause): Handle PRAGMA_OACC_CLAUSE_
to get libgomp.oacc-c++/this.C to work.
I've committed this patch to openacc-gcc-8-branch.
Cesar
2018-10-30 Cesar Philippidis
gcc/cp/
* parser.c (cp_parser_omp_clause_name): Scan for attach and detach.
(cp_parser_oacc_data_clause): Handle PRAGMA_OACC_CLAUSE_{ATTA
This patch introduces a couple of compiler tests for the OpenACC
attach and detach clauses.
I've committed it to openacc-gcc-8-branch.
Cesar
2018-10-30 Cesar Philippidis
gcc/testsuite/
* c-c++-common/goacc/mdc-1.c: New test.
* c-c++-common/goacc/mdc-2.c: New test.
* g++.dg/goacc/
On 10/5/18 07:07, Tom de Vries wrote:
> On 6/29/18 8:19 PM, Cesar Philippidis wrote:
>> The attached patch includes the nvptx and GCC ME reductions enhancements.
>>
>> Is this patch OK for trunk? It bootstrapped / regression tested cleanly
>> for x86_64 with nvptx off
t if this patch is OK, I've decided to leave that
as-is for now.
Cesar
2016-08-02 Cesar Philippidis
gcc/fortran/
* openmp.c (resolve_oacc_data_clauses): Emit a warning about a
potentially non-contiguous array pointer.
(resolve_omp_clauses): Extend coverage of OpenACC da
t =;
> + }
> + if (clauses->seq)
> + {
> + tree c =uild_omp_clause (loc, OMP_CLAUSE_SEQ);
> + OMP_CLAUSE_CHAIN (c) =lauses_t;
> + clauses_t =;
> + }
> +}
> + verify_oacc_routine_clauses (&clauses_t, loc);
included elsewhere in your patch set? I'll take over this patch as I
work on PR72741.
Cesar
On 08/11/2016 08:18 AM, Thomas Schwinge wrote:
>> --- a/gcc/fortran/module.c
>> +++ b/gcc/fortran/module.c
>
>> [...]
>> +DECL_MIO_NAME (oacc_function)
>> [...]
>
> As discussed between Cesar and Tobias, these module.c/symbol.c changes
> introduce an
linedocs/gfortran/Interoperability-with-C.html>.
Basically, those library calls need a function interface with a special
C binding. The function I tested in host_data-2.f90 is cublasSaxpy.
Other function interfaces will need to be created as necessary.
I've applied this patch to gomp-4_0-br
On 08/11/2016 03:38 PM, Cesar Philippidis wrote:
> This patch ports libgomp.oacc-c-c++-common/host_data-1.c to fortran.
> Fortunately, the existing fortran host_data infrastructure was already
> in place, so I had to do was port over the calls to Nvidia's CUDA BLAS
> library.
On 08/11/2016 09:26 AM, Thomas Schwinge wrote:
> As Cesar asked for it, there is now a Git branch
> tschwinge/omp/pr72741-wip containing these changes (plus some other
> pending changes that I didn't single out at this time), at
> <https://gcc.gnu.org/git/?p=gcc.git;a=s
n the meantime, I'll apply this WIP patch to gomp-4_0-branch.
Cesar
2016-08-17 Cesar Philippidis
PR middle-end/70828
gcc/
* gimplify.c (struct gimplify_omp_ctx): Add tree clauses member.
(new_omp_context): Initialize clauses to NULL_TREE.
(gimplify_scan_omp_clauses): Set clau
ine.
> gcc/cp/
> * parser.c (cp_finalize_oacc_routine): Rework checking if already
> marked as an accelerator routine.
> gcc/testsuite/
> * c-c++-common/goacc/oaccdevlow-routine.c: Update.
This test case is missing in both gomp4 and the git diff --stat below.
Ces
ks and that warning for unutilized parallelism.
I've applied this patch, which addresses the acc routine test coverage
deficiencies in fortran, to gomp-4_0-branch.
Cesar
2016-08-19 Cesar Philippidis
gcc/testsuite/
* gfortran.dg/goacc/routine-8.f90: New test.
* gfortran.dg/goacc/routine-level
determined by gomp_map_vars, which this patch does.
This issue was causing SPEC_ACCEL 304.olbm to generate bogus results and
fail during specdiff. I've applied patch to gomp-4_0-branch.
Cesar
2016-08-23 Cesar Philippidis
libgomp/
* oacc-parallel.c (GOACC_parallel_keyed): Add offset to deva
c_routines pass in order to identify if a variable is a
function or variable because that information isn't available during
matching.
I've applied this patch to gomp-4_0-branch.
Cesar
2016-08-26 Cesar Philippidis
gcc/fortran/
* gfortran.h (enum oacc_function): Make OACC_FUNCTION
k acc loops inside acc kernels regions, so perhaps it
would be better to leave the end user with more flexibility. On the
other hand, it's debatable whether do concurrent loops should even be
permitted inside acc offloaded regions.
I've applied this patch to gomp-4_0-branch. Is this OK for t
ility. Perhaps I
should a warning for implicitly used assumed-sizes arrays?
I've applied this patch to gomp-4_0-branch. It looks like OpenMP has a
similar problem.
Cesar
2016-08-30 Cesar Philippidis
gcc/
* omp-low.c (lower_omp_target): Handle NULL-sized types for
assumed-sized arrays.
On 05/23/2016 11:09 PM, Jakub Jelinek wrote:
> On Mon, May 23, 2016 at 07:31:53PM -0700, Cesar Philippidis wrote:
>> @@ -12559,7 +12560,7 @@ c_finish_omp_clauses (tree clauses, enum
>> c_omp_region_type ort)
>>t = OMP_CLAUSE_DECL (c);
>>if
This patch fixes a bootstrap failure that I encountered while
backporting the firstprivate subarray patch to gomp-4_0-branch. I've
applied it to gomp4.
Cesar
2016-05-27 Cesar Philippidis
* gcc/omp-low.c (oacc_loop_auto_partitions): Use boolean OR
when comparing outer_assign adn loop-&
This patch backports the gfc_match_omp_clauses restructuring changes
that occurred early this month in trunk to gomp-4_0-branch. Now it's
easier to detect which of our local changes in gomp4 are not present in
trunk yet.
Cesar
2016-05-27 Cesar Philippidis
Backport trunk r235922:
2016-
private pointer changes.
Cesar
2016-05-27 Cesar Philippidis
gcc/testsuite/
* c-c++-common/goacc/kernels-loop-offload-alias-none.c: Add xfails.
* c-c++-common/goacc/kernels-loop-offload-alias-ptr.c: Likewise.
* c-c++-common/goacc/kernels-offload-alias-2.c: Likewise.
* c-c++-common/goacc/kernel
On 05/31/2016 08:45 AM, Thomas Schwinge wrote:
> While working on something else, I came across the following. Cesar, can
> you please verify that this is really dead code in the Fortran front end,
> which currently is the only producer of OMP_CLAUSE_DEVICE_RESIDENT?
You're co
+ if (TREE_CODE (TREE_TYPE (decl)) != ARRAY_TYPE)
>> + break;
>
> Likewise.
>
> Also add a "/* FALLTHRU */" comment here.
>
>> case OMP_TARGET_DATA:
>> case OMP_TARGET_ENTER_DATA:
>> case OMP_TARGET_EXIT_DATA:
>> +case OACC_ENTER_DATA:
>> +case OACC_EXIT_DATA:
>> case OACC_HOST_DATA:
>>if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER
>>|| (OMP_CLAUSE_MAP_KIND (c)
> | == GOMP_MAP_FIRSTPRIVATE_REFERENCE))
> | /* For target {,enter ,exit }data only the array slice is
> |mapped, but not the pointer to it. */
> | remove = true;
> | break;
> | default:
> | break;
> | }
>
> By the way, why is this not relevant for the OpenACC update and OpenMP
> target update directives, OACC_UPDATE and OMP_TARGET_UPDATE? Is it
> because theses only update existing mappings but don't create new ones?
I suppose they can be added here, but lower_omp_target already ignores
GOMP_MAP_FIRSTPRIVATE_POINTER for non-offloaded and data_region regions.
Cesar
I had already fixed pr70688 in trunk r236678 with the patch I introduced
here <https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00762.html>. This
patch introduces a new libgomp test case to verify the fix. I'll apply
this patch to trunk and gomp4 as obvious.
Cesar
2016-06-01 Cesar
handle GOMP_MAP_POINTER,
because subarray pointers are now firstprivate.
Is this OK for trunk?
Cesar
2016-06-01 Cesar Philippidis
gcc/c/
* c-parser.c (c_parser_oacc_declare): Don't scan for
GOMP_MAP_POINTER.
* c-typeck.c (handle_omp_array_sections): Mark data clauses with
GOMP_MAP_F
aps even
> combined with another clause without any space in between etc.
Both acc wait and async accept optional parenthesis arguments. E.g.,
#pragma acc wait
blocks for all of the async streams to complete before proceeding, whereas
#pragma acc wait (1, 5)
only blocks for async streams 1 and 5.
Cesar
Ping.
Cesar
On 06/01/2016 02:35 PM, Cesar Philippidis wrote:
> This patch teaches c and c++ front ends and omp-low how to deal with
> subarray involving GOMP_MAP_FORCE_{PRESENT,TO,FROM,TOFROM} data
> mappings. As the libgomp test case shows, it might be possible for a
> subarray
ereference garbage. This is a problem with pass-by-reference
in general.
Cesar
2016-06-15 Cesar Philippidis
gcc/
* cgraphunit.c (ipa_passes): Only stream offloaded code when
flag_generate_offload is positive.
(symbol_table::compile): Likewise.
* common.opt (flag_generate_offload): Update comme
On 06/07/2016 08:02 AM, Jakub Jelinek wrote:
> On Tue, Jun 07, 2016 at 08:01:10AM -0700, Cesar Philippidis wrote:
>> On 06/07/2016 04:13 AM, Jakub Jelinek wrote:
>>
>>> I've noticed
>>> if ((mask & OMP_CLAUSE_WAIT)
>>>
h can consolidate them. I was able to eliminate a lot of
duplicate code with this function.
Is this ok for trunk and gcc-6?
Cesar
301 - 400 of 637 matches
Mail list logo
