-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 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
,
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
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
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
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/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
.
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
:] 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
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
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
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
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
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
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
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
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
-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 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
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
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/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
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
.
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
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
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 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
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
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
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
, 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
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
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
.
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
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
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
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
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
and no regressions showed up.
Thanks,
Cesar
2013-10-10 Cesar Philippidis ce...@codesourcery.com
gcc/
* regs.h (REG_N_GROW): New function.
* combine.c (combine_split_insns): Call REG_N_GROW when
new registers are created.
Index: gcc/regs.h
converting that array to a vec. But I don't want to
touch more code than I have to right now. Is this OK as a stopgap?
Thanks for the review!
Cesar
2013-10-11 Cesar Philippidis ce...@codesourcery.com
gcc/
* regs.h (REG_N_GROW): New function.
* combine.c (combine_split_insns
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 in
Yocto. Both gcc-trunk, gcc-4.8 and all of the targets are potentially
affected
On 6/20/13 9:49 AM, Mike Stump wrote:
On May 30, 2013, at 12:59 PM, Cesar Philippidis ce...@codesourcery.com
wrote:
Here is a patch from our backlog at Mentor Graphics that addresses a
libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following
error with dejagnu
Is it OK
are specified. The testsuite used to set those flags prior to Benjamin's
patch to remove duplicate cxxflags here
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01572.html.
Is this OK for trunk? If so, please apply.
Thanks,
Cesar
2013-10-28 Cesar Philippidis ce...@codesourcery.com
libstdc
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 ce...@codesourcery.com
gcc
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 ce...@codesourcery.com
gcc
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
ce...@codesourcery.com 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 does not trap
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
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 CXXFLAGS
* missing -g -O2 for remote targets
The duplicate
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 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
-linker-plugin}} does not exist.
This problem usually does not occur since the default site.exp does not
contain ENABLE_LTO=1. I tested both with and without our custom site.exp.
Is it OK for trunk? If so, please check it in since I do not have commit
rights.
Cesar Philippidis
2013-05-30 Iain
not exist.
This problem usually does not occur since the default site.exp does not
contain ENABLE_LTO=1. This patch has been tested both with and without
our custom site.exp.
Is this OK for trunk? If so, please check it in since I do not have commit
rights.
Cesar Philippidis
2013-05-30 Iain
This patch from libffi revision 675c9839224 allows libffi.pdf to be
generated without tex related errors. I tested it on gcc trunk. Please
backport it to gcc. The original patch can be found here:
http://sourceware.org/ml/libffi-discuss/2013/msg00086.html
Cesar
2013-06-03 Andreas Schwab
multiple inheritance, and that triggered the
problem.
I tested this patch with the default ARM and THUMB multilibs in
additional to -march=armv6-m.
OK for trunk?
Cesar
2013-06-06 Julian Brown jul...@codesourcery.com
Cesar Philippidis ce...@codesourcery.com
gcc
. Is the new comment OK? If so,
please check it in since I do not have SVN write access.
Thanks,
Cesar
2013-06-07 Julian Brown jul...@codesourcery.com
Cesar Philippidis ce...@codesourcery.com
gcc/
* config/arm/arm.c (arm_output_mi_thunk): Fix offset
On 6/10/13 8:32 AM, Richard Earnshaw wrote:
On 07/06/13 17:50, Cesar Philippidis wrote:
On 6/6/13 9:00 AM, Richard Earnshaw wrote:
The pipeline offset is 4 for Thumb2 as well. So at the very least you
need to explain why your change doesn't apply then as well.
Yes some context is lost
Ping.
Cesar
On 5/30/13 12:59 PM, Cesar Philippidis wrote:
Here is a patch from our backlog at Mentor Graphics that addresses a
libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following
error with dejagnu:
ERROR: (DejaGnu) proc libgomp_target_compile linker_plugin9263.c
Ping.
Cesar
On 5/30/13 1:02 PM, Cesar Philippidis wrote:
Here is a patch from our backlog that addresses a libitm issue where
setting ENABLE_LTO=1 in site.exp causes the following error with dejagnu:
ERROR: (DejaGnu) proc libitm_target_compile linker_plugin19344.c
linker_plugin19344.exe
Ping.
Cesar
On 6/7/13 9:50 AM, Cesar Philippidis wrote:
On 6/6/13 9:00 AM, Richard Earnshaw wrote:
The pipeline offset is 4 for Thumb2 as well. So at the very least you
need to explain why your change doesn't apply then as well.
Yes some context is lost in that comment. Thunks
refine_range_plus (). Also, TODO_ggc_collect has been removed in the
gimple_opt_pass struct.
I bootstrapped and regression tested on x86_64-unknown-linux-gnu and
arm-none-linux-gnueabi. OK for trunk?
Cesar
2013-06-21 Tom de Vries t...@codesourcery.com
Cesar Philippidis ce
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
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
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 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
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 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.
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[] =
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
. 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
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
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
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
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
. 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
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
1 - 100 of 620 matches
Mail list logo
