On 08/06/2014 07:23 PM, David Malcolm wrote:
diff --git a/gcc/function.h b/gcc/function.h
index 28a20f3..ba7597c 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -135,7 +135,7 @@ struct GTY(()) expr_status {
rtx x_apply_args_value;
/* List of labels that must never be deleted. */
-
On 08/07/2014 09:50 PM, Bernd Schmidt wrote:
The following patch reworks this area - instead of trying to find a
proper pointer type, it just recognizes the case where an integer is
promoted to be the base, and performs all calculations in that type
rather than sizetype. That also seems
Some code I added for the ptx backend triggered tree-checking failures
for gimple created in tree-nested: we can end up taking the address of
an SSA_NAME, which seems invalid. The problem is that code in
tree-nested wants to change the rhs of an existing assignment, but just
using
On 07/23/2014 04:37 PM, Ilya Verbin wrote:
On 23 Jul 16:16, Bernd Schmidt wrote:
Here's the latest version, which fixes some more issues and removes
things that are now unnecessary. Configure scripts and toplevel
autogenned stuff is left out and must be regenerated.
Are you OK with me
On 07/24/2014 02:38 PM, Martin Jambor wrote:
This seems to be the statement which has its RHS converted to to a
MEM_REF[_6], am I right? I wonder whether it is correct input
though, because it looks like it has mismatched types. The LHS is
clearly an aggregate of type struct S while the RHS is
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00616.html
On 06/06/2014 05:07 PM, Bernd Schmidt wrote:
There's a problem when offloading from a compiler for one target machine
to another: the machine specific options don't necessarily match. This
patch tries to address this.
The idea
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
On 27 Jun 09:32, Bernd Schmidt wrote:
Sorry for the delayed reply, I was travelling. There seem to be some
thinkos in the configure script and Makefile; can you try the
following (don't forget to regenerate configure)? It seems to work
for ptx
This is an idea I discussed with a few folks at the Cauldron, and since
they made supportive noises, I decided to work on it. The problem I'm
trying to solve is that for ptx, I'll have to mark a lot of testcases as
unsupported (uses of things such as indirect jumps, alloca, and
sometimes
work after I
get some patches installed. ]
For reference, I'm attaching my current version of ptx mkoffload.
Bernd
/* Offload image generation tool for ptx
Nathan Sidwell nat...@codesourcery.com
Bernd Schmidt ber...@codesourcery.com
Munges PTX assembly into a C source file defining
On 07/22/2014 01:24 PM, Thomas Schwinge wrote:
On Tue, 22 Jul 2014 13:06:19 +0200, Bernd Schmidt
ber...@codesourcery.com wrote:
It says Immutable Page, so I can't seem to edit it.
Probably applies for your write access to any wiki page, and that's
because you've not been added to thw
On 02/28/2014 11:48 PM, Marc Glisse wrote:
/* Optimize
+ ptr = malloc (n);
+ memset (ptr, 0, n);
+ into
+ ptr = calloc (n);
+ gsi_p is known to point to a call to __builtin_memset. */
Is there anything in here to prevent us making an infinite loop if the
above pattern occurs in a
I noticed that we set node-definition = true in varpool_assemble_decl.
The surrounding code suggests that we should only ever get there if
definition is already true, so I changed it to an assert. The question
is interesting for some modifications I'm making for ptx (which requires
On 07/10/2014 08:24 PM, Ilya Verbin wrote:
On 07 Jul 17:03, Bernd Schmidt wrote:
Is libgomp the only problematic one? (Does the accel compiler even
need one?) It seems to be installed in /usr/lib rather than in a
gcc-specific directory, which is a little surprising to me. It may
be necessary
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
2) Or should I build accel compiler as a cross from
x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
Yes, that's the general idea.
Will it help to distinguish the libs?
Is libgomp the only problematic one? (Does the accel compiler even need
On 07/03/2014 06:12 PM, DJ Delorie wrote:
The hardware transfers data in and out of byte-oriented memory in
TYPE_SIZE_UNITS chunks. Once in a hardware register, all operations
are either 8, 16, or 20 bits (TYPE_SIZE) in size. So yes, values are
padded in memory, but no, they are not padded in
On 06/17/2014 04:54 PM, Martin Jambor wrote:
Weird... does the following (untested) patch help?
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 0afa197..747b1b6 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -3277,6 +3277,8 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator
*gsi)
On 06/19/2014 12:19 PM, Ilya Verbin wrote:
On 18 Jun 16:22, Bernd Schmidt wrote:
What I think you need to do is
For the first compiler:
--enable-as-accelerator-for=x86_64-pc-linux-gnu
--target=x86_64-intelmic-linux-gnu --prefix=/somewhere
No --enable-accelerator options at all. This should
I discovered that create_tmp_var is used in the gfortran frontend to
create static variables. IMO the function is not intended to do this,
and it causes problems for a modification I need to make to it which
assumes that it only creates local variables. So I've made a patch to
make fortran
On 06/18/2014 04:13 PM, Ilya Verbin wrote:
On 17 Jun 21:22, Bernd Schmidt wrote:
On 06/17/2014 08:20 PM, Ilya Verbin wrote:
I don't get this part of the plan. Where a host compiler will look for
mkoffloads?
E.g., first I configure/make/install the target gcc and corresponding mkoffload
On 06/17/2014 08:20 PM, Ilya Verbin wrote:
Hello Bernd,
On 28 Feb 17:21, Bernd Schmidt wrote:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it
into locations where
: Bernd Schmidt ber...@codesourcery.com
Date: Wed Jun 11 18:41:09 2014 +0200
Fix an issue with regimplification.
This is in preparation for the lower-address-spaces pass for the ptx port. We
need to teach the regimplifier how to handle the case when an ADDR_EXPR turns
There's code in regimplification that makes us use an extra temporary
when we encounter a call returning a non-BLKmode structure. This seems
somewhat inefficient and unnecessary, and when used from the
lower-addr-spaces pass I'm working on it leads to problems further
down that look like tree-ssa
: gimplify_arg uses is_gimple_lvalue in some cases
instead of is_gimple_val, and regimplification needs to match that.
Bootstrapped and tested on x86_64-linux, ok?
Bernd
commit c1296ac4f4e7e8f0fb9c87d71ca8194a8eac0067
Author: Bernd Schmidt ber...@codesourcery.com
Date: Wed Jun 11 18:41:09 2014
On 06/16/2014 01:24 PM, Richard Biener wrote:
On Mon, Jun 16, 2014 at 12:56 PM, Bernd Schmidt ber...@codesourcery.com wrote:
For the ptx port, I've needed to write a new pass which ensures all objects
go into address spaces as required by the machine. This uses the
regimplification code
On 06/16/2014 07:26 PM, Mike Stump wrote:
On Jun 16, 2014, at 3:56 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
For the ptx port, I've needed to write a new pass which ensures all
objects go into address spaces as required by the machine.
I have such a machine and I’ve always approached
On 05/25/2014 11:35 AM, Richard Sandiford wrote:
Bernd Schmidt bernds_...@t-online.de writes:
On 02/13/2014 10:18 AM, Richard Sandiford wrote:
contrib/
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems suitable.
I'm now seeing
On 04/17/2014 08:33 PM, Ilya Verbin wrote:
Could you please take a look at this patch? It fixes the ordering issue in the
tables stated above, and passes all the tests that I have. But I'm not sure
about its correctness from the architectural point of view.
I'm still skeptical relying on
af9bca9c6439e3f8f31b40d5813a3d016b1f21e5
Author: Bernd Schmidt ber...@codesourcery.com
Date: Wed May 21 12:18:17 2014 +0200
Make a collect-utils library for use by tools like collect2 and lto-wrapper.
* Makefile.in (ALL_HOST_BACKEND_OBJS): Add collect-utils.o.
(lto-wrapper$(exeext)): Link with collect
There's a problem when offloading from a compiler for one target machine
to another: the machine specific options don't necessarily match. This
patch tries to address this.
The idea is that since we have two options sections anyway, with
different section name prefixes, we can arrange to pass
On 06/04/2014 10:36 PM, Tobias Burnus wrote:
Bernd Schmidt wrote:
Even with this applied, I'm still seeing similar failures.
I didn't claim that the patch would fix everything – nor that it was
well tested.
Just wanted to report back since the problem doesn't really show up on
normal
On 06/04/2014 09:40 AM, Tobias Burnus wrote:
Still untested patch, but I cannot resist pointing out stupid
typos by myself.
I intent to tests the build and test the patch - and then to
commit it as obvious. If you see problems with this approach
please scream now.
I have no idea about the
On 06/04/2014 09:40 AM, Tobias Burnus wrote:
Still untested patch, but I cannot resist pointing out stupid
typos by myself.
I intent to tests the build and test the patch - and then to
commit it as obvious. If you see problems with this approach
please scream now.
Even with this applied, I'm
On 05/27/2014 04:01 PM, Tobias Burnus wrote:
Bernd Schmidt wrote:
Compiling Fortran code with the ptx backend I'm working on results in
assembler warnings about mismatch between function calls and function decls.
Bootstrapped and tested on x86_64-linux. Ok?
OK.
The change/bug is due to my
On 05/27/2014 04:57 PM, Richard Biener wrote:
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt ber...@codesourcery.com wrote:
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY for STRING_CST (and subsequently noticed that nothing seems to
set it for COMPLEX_CST
On 05/27/2014 12:17 PM, Ilya Verbin wrote:
2014-03-01 1:40 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
For your use case, I'd imagine the offload compiler would be built
relatively normally as a full build with
--enable-as-accelerator-for=x86_64-linux, which would install it into
locations
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
2014-05-27 14:59 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There isn't a way to do this. For ptx, target libraries can't be built
anyway. For your use case, I'd recommend building the offload gcc first,
installing it, and then building the host
On 05/22/2014 05:56 PM, Joseph S. Myers wrote:
On Thu, 22 May 2014, Bernd Schmidt wrote:
The implementations of some functions like fork_execute are changed to those
from collect2 and the calls in lto-wrapper adapted accordingly. There are some
minor changes in these functions: for example I
I noticed that string constants built by the Fortran frontend don't set
TREE_READONLY for STRING_CST (and subsequently noticed that nothing
seems to set it for COMPLEX_CST). That was confusing the ptx backend I'm
working on.
The -fwritable-strings option for C was removed a while ago, so I
Compiling Fortran code with the ptx backend I'm working on results in
assembler warnings about mismatch between function calls and function
decls. This seems to be a bug in the Fortran frontend, where a decl for
_gfortran_caf_init is created with four arguments, while the library
function is
When putting a constant into the constant pool, we make a copy of the
tree in build_constant_desc. This caused me some problems with the ptx
backend, which has a pass to modify the address spaces of all variables
and constants to match the requirements of the backend. It would be nice
for it
On 05/27/2014 05:33 PM, Ilya Verbin wrote:
2014-05-27 15:15 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
On 05/27/2014 01:11 PM, Ilya Verbin wrote:
Do I understand correctly that you recommend to build our offload gcc
manually, rather than during configure/make?
Well, configure/make
On 02/13/2014 10:18 AM, Richard Sandiford wrote:
contrib/
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems suitable.
I'm now seeing the following:
Traceback (most recent call last):
File
On 05/23/2014 10:07 AM, shmeel gutl wrote:
Exposed pipeline is not my problem. Negative latency is my problem. I
don't see negative latency for c6x, not in unit reservations and not in
adjust cost. Did I miss something?
You just need to model it differently. Rather than saying instruction A
On 05/21/2014 05:30 PM, Vladimir Makarov wrote:
On 2014-05-20, 5:18 PM, shmeel gutl wrote:
The problem that I see is that the haifa scheduler schedules one cycle
at a time, in a forward order, by picking from a list of instructions
that can be scheduled without delays. So, in the above example,
?
Bernd
commit f2f3cb92d29cd1940771bf4297055aed3ee86251
Author: Bernd Schmidt ber...@codesourcery.com
Date: Wed May 21 15:04:47 2014 +0200
Create a new header lto-section-names.h
gcc/
* config/darwin.c: Include lto-section-names.h.
(LTO_SEGMENT_NAME): Don't
?
Bernd
commit 1faf8f4aa2f81be4a0b0db8c89933e9c5bd2abcb
Author: Bernd Schmidt ber...@codesourcery.com
Date: Wed May 21 15:15:45 2014 +0200
Make a collect-utils library for use by tools like collect2 and lto-wrapper.
* Makefile.in (ALL_HOST_BACKEND_OBJS): Add collect-utils.o
39e9b2e3b47c893fcc1d96dfa7bdd975da80633e
Author: Bernd Schmidt ber...@codesourcery.com
Date: Wed May 21 16:44:03 2014 +0200
Part 2 of the collect-utils library, now also used for collect2.
* Makefile.in (COLLECT2_OBJS): Add collect-utils.o.
(LTO_WRAPPER_OBJS): New variable.
(lto
On 01/09/2014 05:20 AM, Jeff Law wrote:
On 01/07/14 09:07, Bernd Schmidt wrote:
If someone explicitly chooses that option we can turn off the reordering
in hw-doloop. That should happen sufficiently rarely that it isn't a
problem. That's what the patch below does - bootstraped on x86_64-linux
@@
2014-05-21 Bernd Schmidt ber...@codesourcery.com
+ * config/bfin/bfin.c (split_load_immediate): Use gen_int_mode in a few
+ more places.
+
* cfgrtl.c (cfg_layout_initialize): Weaken assert to only trigger if
flag_reorder_blocks_and_partition.
* hw-doloop.c (reorg_loops): Avoid reordering
On 01/07/2014 05:22 PM, Bernd Schmidt wrote:
This fixes a problem identified by Chung-Lin. Once reload is done, all
equivalencing insns for pseudos that didn't get a hard reg but could be
eliminated using their REG_EQUIV are deleted. However, we still can
produce reloads and reload insns
On 06/19/2013 07:39 PM, Bernd Schmidt wrote:
This is bug that triggers on m68k. The loop unroller creates a MULT
expression and tries to force it into a register, which causes a libcall
to be generated. Since args are pushed we create a
(use (mem (plus virtual_outgoing_args scratch
There was a patch to change GET_CODE(..) == CONST_INT to CONST_INT_P,
and in one instance this was done incorrectly, leaving only a plain
GET_CODE without any comparison. I've committed the following as
obvious after testing on x86_64-linux.
Bernd
* simplify-rtx.c
On 05/08/2014 12:11 PM, Bernd Schmidt wrote:
On 05/06/2014 05:32 PM, Ilya Verbin wrote:
On 05 Apr 17:22, Bernd Schmidt wrote:
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should
just go back to the previous
On 05/06/2014 05:32 PM, Ilya Verbin wrote:
On 05 Apr 17:22, Bernd Schmidt wrote:
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should
just go back to the previous version of this patch which didn't try
to use
On 04/05/2014 05:04 PM, Thomas Schwinge wrote:
Is it a linker bug that I need to add something like the following?
--- libgcc/ompstuff.c
+++ libgcc/ompstuff.c
@@ -40,6 +40,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include libgcc_tm.h
#if
On 04/04/2014 07:55 AM, Thomas Schwinge wrote:
Hi!
On Thu, 3 Apr 2014 18:13:08 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
Yes, it does, thanks! Please revert my patch
On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
On Fri, Mar 21, 2014 at 04:13:45PM +0100, Bernd Schmidt wrote:
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my strong preference was that
either this lives in some other crt object that mkoffload/linker
On 03/20/2014 06:08 PM, Bernd Schmidt wrote:
This is based on Michael Zolotukhin's patch 3/3 from a while ago. It
enables lto-wrapper to build target images using the offload compilers
(identifying them through an env variable passed in by the gcc driver).
All the target-specific code is gone
On 04/02/2014 10:36 AM, Thomas Schwinge wrote:
I see regressions in the libgomp testsuite for configurations where
offloading is not enabled:
spawn [...]/build/gcc/xgcc -B[...]/build/gcc/
[...]/source/libgomp/testsuite/libgomp.c/for-3.c
-B[...]/build/x86_64-unknown-linux-gnu/./libgomp/
On 04/03/2014 06:53 PM, Ilya Verbin wrote:
2014-04-03 20:13 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
The patch below should be a better fix, making the references to
__OPENMP_TARGET__ weak. Does this work for you?
Shouldn't we just remove __OPENMP_TARGET__ argument from GOMP_target
On 04/03/2014 07:25 PM, Ilya Verbin wrote:
Yes, initially the idea was to use it for look up the right function.
But now each DSO will call GOMP_offload_register, and pass unique
pointer to __OPENMP_TARGET__ (host_table) for this DSO. Then
gomp_register_images_for_device registers all this host
On 03/27/2014 02:50 PM, Felix Yang wrote:
I find DCE in sched2 is disabled for C6X backend. Is this a
performance consideration? Or a GCC BUG?
As far as I remember, it's a problem due to how delayed instructions are
represented to the final scheduler. Just before that scheduling pass is
On 03/27/2014 02:31 PM, Ilya Verbin wrote:
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both host gcc and target
On 03/27/2014 02:31 PM, Ilya Verbin wrote:
+#ifdef ACCEL_COMPILER
+ /* Decls are placed in reversed order in fat-objects, so we need to
+ revert them back if we compile target. */
...
Actually this change is incorrect. If host binary is built with -flto, then
both host gcc and target
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my strong preference was that
either this lives in some other crt object that mkoffload/linker plugin adds
to link, or that it would be completely mkoffload synthetized.
mkoffload is only concerned with
On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
And, what is the exact reason why you are using protected visibility rather
than hidden?
Also, supposedly if you've used section names without . in them, the linker
itself would provide the symbols automatically and you wouldn't actually
need
===
--- ChangeLog (revision 208706)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2014-03-20 Bernd Schmidt ber...@codesourcery.com
+
+ From Nathan Sidwell and Thomas Schwinge.
+ * configure.ac: Add --enable-accelerator.
+ * configure: Rebuilt.
+
2014-03-04 Jonathan
/ChangeLog (working copy)
@@ -1,3 +1,26 @@
+2014-03-20 Bernd Schmidt ber...@codesourcery.com
+
+ * configure.ac (real_target_noncanonical, tool_prefix,
+ accel_dir_suffix, offload_targets): Compute new variables.
+ (--enable-as-accelerator-for, --enable-as-accelerator,
+ --enable-offload-targets): New
(working copy)
@@ -1,3 +1,9 @@
+2014-03-20 Bernd Schmidt ber...@codesourcery.com
+
+ * lto-object.c: Include lto-section-names.h.
+ (LTO_SEGMENT_NAME): Don't define.
+ * lto.c: Include lto-section-names.h.
+
2014-02-14 Jan Hubicka hubi...@ucw.cz
PR lto/60295
Index: gcc/ChangeLog
/ChangeLog (revision 208720)
+++ gcc/lto/ChangeLog (working copy)
@@ -1,5 +1,11 @@
2014-03-20 Bernd Schmidt ber...@codesourcery.com
+ From Michael Zolotukhin.
+ * lto-object.c (lto_obj_add_section): Compare against the
+ section_name_prefix variable.
+ * lto.c (lto_section_with_id): Likewise
@@
+2014-03-20 Bernd Schmidt ber...@codesourcery.com
+
+ * crtstuff.c (_omp_func_table, _omp_var_table, _omp_funcs_end,
+ _omp_vars_end): New array fragments.
+ (__OPENMP_TARGET__): New variable.
+
2014-02-28 Joey Ye joey...@arm.com
PR libgcc/60166
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 208723)
+++ gcc/ChangeLog (working copy)
@@ -1,5 +1,17 @@
2014-03-20 Bernd Schmidt ber...@codesourcery.com
+ * Makefile.in (ALL_HOST_BACKEND_OBJS): Add collect-utils.o.
+ (lto-wrapper$(exeext)): Link with collect-utils.o.
+ * collect
===
--- gcc/ChangeLog (revision 208724)
+++ gcc/ChangeLog (working copy)
@@ -1,5 +1,40 @@
2014-03-20 Bernd Schmidt ber...@codesourcery.com
+ * Makefile.in (COLLECT2_OBJS): Add collect-utils.o.
+ (LTO_WRAPPER_OBJS): New variable.
+ (lto-wrapper$(exeext
@@
2014-03-20 Bernd Schmidt ber...@codesourcery.com
+ Mostly by Michael Zolotukhin:
+ * lto-wrapper.c (OFFLOAD_FUNC_TABLE_SECTION_NAME,
+ OFFLOAD_TARGET_NAMES_ENV): New defines.
+ (offload_names): New static variable.
+ (free_array_of_ptrs, parse_env_var, access_check,
+ prepare_target_image
On 03/12/2014 03:51 PM, Ilya Verbin wrote:
2014-03-12 18:12 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
LGTM. Shall I start committing my changes to the branch?
Yes, I think you should commit your changes.
And we will rewrite our part to use the new configure approach.
Done now. I
On 03/20/2014 06:03 PM, Bernd Schmidt wrote:
This is the second part of making a set of utility functions to be used
by collect2, lto-wrapper and mkoffload.
The implementations of some functions like fork_execute are changed to
those from collect2 and the calls in lto-wrapper adapted
Hi,
On 03/08/2014 03:50 PM, Ilya Verbin wrote:
Here is updated patch for libgomp. It assumes that there is a constructor with
a call to GOMP_offload_register in every target image, created by mkoffload
tool. How does this look?
LGTM. Shall I start committing my changes to the branch?
On 03/05/2014 06:15 PM, Ilya Verbin wrote:
On 28 Feb 17:21, Bernd Schmidt wrote:
I think it won't help that much - I still think this entire scheme
is likely to fail on nvptx. I'll try to construct an example at
some point.
One other thing about the split tables is that we don't have to
write
On 03/06/2014 12:11 PM, Ilya Verbin wrote:
Do I understand correctly, that you propose to do so:
extern void *_omp_host_func_table[];
extern void *_omp_host_var_table[];
extern void *_omp_host_funcs_end[];
extern void *_omp_host_vars_end[];
void *__OPENMP_TARGET_HOST__[]
__attribute__
On 03/03/2014 11:01 PM, Richard Sandiford wrote:
I'll run a full test overnight, but does this look like it might be
a way out, at least for 4.9?
Pretty much agree with everything you've written in this thread. I
think this patch is fine.
gcc/
* builtins.c
On 02/28/2014 05:09 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
* Functions and variables now go into different tables, otherwise
intermixing between them could be a problem that causes tables to
go out of sync between host and target
On 02/28/2014 05:21 PM, Bernd Schmidt wrote:
On 02/28/2014 05:09 PM, Ilya Verbin wrote:
Unfortunately I don't fully understand this configure magic... When a
user specifies 2 or 3 accelerators during configuration with
--enable-accelerators, will several different accel-gccs be built
On 02/21/2014 04:17 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt ber...@codesourcery.com:
There were still a number of things in these patches that did not make sense
to me and which I've changed. Let me know if there was a good reason for the
way some of these things were
On 02/14/2014 03:49 PM, Ilya Verbin wrote:
Hi Bernd and Thomas,
Are you planning to support offloading from DSO in PTX/CUDA
environment? If yes, how are you going to solve the problem of the
collision of function names from different DSOs?
What I'm currently trying to do is to use
On 02/14/2014 04:12 PM, Jakub Jelinek wrote:
On Fri, Feb 14, 2014 at 04:01:46PM +0100, Bernd Schmidt wrote:
What I'm currently trying to do is to use get_file_function_name,
which should provide a unique string that can be used to look up an
offloaded function. That was suggested by Nathan
On 01/28/2014 01:52 PM, Ilya Verbin wrote:
The table is used in libgomp (see my patch [1]), as proposed by Jakub
(see [2]). The idea is that the order of entries in the host and
target tables must be identical. This allows to set up one-to-one
correspondence between host and target addresses.
On 12/17/2013 12:39 PM, Michael V. Zolotukhin wrote:
Here is a patch 2/3: Add tables generation.
This patch is just a slightly modified patch sent a couple of weeks ago. When
compiling with '-fopenmp' compiler generates a special symbol, containing
addresses and sizes of
On 01/22/2014 11:53 AM, Andrey Turetskiy wrote:
We have some testcases, but they require XeonPhi hardware and a
working libgomp plugin. Our current version of the plugin depends on
some libraries, that are not open-sourced yet, so currently we can’t
share it.
However, you could examine what
On 01/23/2014 10:44 AM, Chung-Lin Tang wrote:
On 14/1/8 12:22 AM, Bernd Schmidt wrote:
This fixes a problem identified by Chung-Lin. Once reload is done, all
equivalencing insns for pseudos that didn't get a hard reg but could be
eliminated using their REG_EQUIV are deleted. However, we still
On 12/17/2013 12:35 PM, Michael V. Zolotukhin wrote:
Here is a set of patches implementing one more piece of offloading support in
GCC. These three patches allow to build a host binary with target image and all
tables embedded. Along with patches for libgomp and libgomp plugin, which
hopefully
On 01/16/2014 09:53 PM, Jeff Law wrote:
I happened to be going through the list of regressions and came across
this again. I went ahead and installed the patch on the trunk and
closed the BZ.
Thanks. I was travelling and decided not to install any patches before
or during that.
Bernd
On 01/05/2014 05:10 PM, Teresa Johnson wrote:
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt ber...@codesourcery.com wrote:
I have a different patch which I'll submit next week after some more
testing. The assert in cfgrtl is unnecessarily broad and really only needs
to trigger if -freorder
This is PR56791. The address inside of an autoinc is reloaded, and the
autoinc is reloaded, but the reload insns are emitted in the wrong order.
As far as I can tell, this is because find_reloads_address_1 has two
methods of pushing a reload for an autoinc, one of them using the
previously
This fixes a problem identified by Chung-Lin. Once reload is done, all
equivalencing insns for pseudos that didn't get a hard reg but could be
eliminated using their REG_EQUIV are deleted. However, we still can
produce reloads and reload insns for them in certain cases, leading to
unnecessary
On 01/05/2014 12:35 PM, Felix Yang wrote:
Ping?
Cheers,
I have a different patch which I'll submit next week after some more
testing. The assert in cfgrtl is unnecessarily broad and really only
needs to trigger if -freorder-blocks-and-partition; there's nothing
wrong with entering cfglayout
On 01/01/2014 02:01 PM, Felix Yang wrote:
cc1 backtrace:
arraysum.c: In function 'test_entry':
arraysum.c:14:1: internal compiler error: in cfg_layout_initialize, at
cfgrtl.c:4233
Please include steps to reproduce bugs.
Attached please find the patch for this ICE.
Since c6x backend choose
On 11/26/2013 07:45 AM, Chung-Lin Tang wrote:
+(define_insn movhi_internal
+ [(set (match_operand:HI 0 nonimmediate_operand =m, r,r, r,r)
+(match_operand:HI 1 general_operand rM,m,rM,I,J))]
Didn't you say you'd removed the J alternative?
+error (only register based stack
On 12/17/2013 12:42 PM, Michael V. Zolotukhin wrote:
Hi everybody,
Here is a patch 3/3: Add invocation of target compiler.
+ /* Run objcopy on TARGET_IMAGE_FILE_NAME. */
+ buf1 = (char*) xmalloc (strlen (.data=.)
+ + strlen (OFFLOAD_IMAGE_SECTION_NAME) + 1);
+ if
I'll be submitting our current ptx backend in a series of 23 patches in
reply to this mail. This is currently a work-in-progress and still rough
around the edges. We'd like to do all our OpenACC work on the gomp4
branch, so I'm submitting this as a proposal to see if it would be
acceptable for
There's some code in get_uncond_jump_length to emit and then delete a
label and a jump. If a target doesn't use register allocation, this
fails a reload_completed || bb != NULL assert in df_insn_delete.
Fixed by instead emitting the two insns into a sequence which we then
just discard.
gcc/
*
1601 - 1700 of 2315 matches
Mail list logo
