On 05/27/2014 04:57 PM, Richard Biener wrote:
On Tue, May 27, 2014 at 3:13 PM, Bernd Schmidt 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). That was conf
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 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/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
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 thes
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 globals/omp_fn-function
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 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 get_file_fu
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 N
On 02/21/2014 04:17 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt :
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 originally
On 02/28/2014 05:09 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt :
* 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 (imagine one big table being
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 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 (expand_builtin_setjmp_r
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 to
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
declaration
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 fu
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.
T
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 K&R-st
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
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 gimple_assign
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 wi
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'
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__ ((visibi
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?
Bernd
ndex: ChangeLog
===
--- ChangeLog (revision 208706)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2014-03-20 Bernd Schmidt
+
+ From Nathan Sidwell and Thomas Schwinge.
+ * configure.ac: Add --enable-accelerator.
+ * configure: Rebuilt.
+
2014-03-04
208706)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,26 @@
+2014-03-20 Bernd Schmidt
+
+ * 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 options
(working copy)
@@ -1,3 +1,9 @@
+2014-03-20 Bernd Schmidt
+
+ * 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
PR lto/6
-- gcc/lto/ChangeLog (revision 208720)
+++ gcc/lto/ChangeLog (working copy)
@@ -1,5 +1,11 @@
2014-03-20 Bernd Schmidt
+ From Michael Zolotukhin.
+ * lto-object.c (lto_obj_add_section): Compare against the
+ section_name_prefix variable.
+ * lto.c (lto_section_with_id): Likewise.
+ (read_cgraph_a
+1,9 @@
+2014-03-20 Bernd Schmidt
+
+ * 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
PR libgcc/60166
Index: gcc/Chan
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 208723)
+++ gcc/ChangeLog (working copy)
@@ -1,5 +1,17 @@
2014-03-20 Bernd Schmidt
+ * Makefile.in (ALL_HOST_BACKEND_OBJS): Add collect-utils.o.
+ (lto-wrapper$(exeext)): Link with collect-utils.o.
+ * colle
===
--- gcc/ChangeLog (revision 208724)
+++ gcc/ChangeLog (working copy)
@@ -1,5 +1,40 @@
2014-03-20 Bernd Schmidt
+ * Makefile.in (COLLECT2_OBJS): Add collect-utils.o.
+ (LTO_WRAPPER_OBJS): New variable.
+ (lto-wrapper$(exeext)): Use it.
+ * collect2.c
+1,15 @@
2014-03-20 Bernd Schmidt
+ 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_
On 03/12/2014 03:51 PM, Ilya Verbin wrote:
2014-03-12 18:12 GMT+04:00 Bernd Schmidt :
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 think/hope that I&#x
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
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 g
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 begin/end
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 gcc
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 gcc
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 :
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,
since we de
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 04/04/2014 07:55 AM, Thomas Schwinge wrote:
Hi!
On Thu, 3 Apr 2014 18:13:08 +0200, Bernd Schmidt
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 when committing yours
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
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 defined(HAVE_GA
On 10/15/11 16:21, Eric Botcazou wrote:
> so the correct fix is very likely something like:
>
> Index: cfgrtl.c
> ===
> --- cfgrtl.c(revision 179844)
> +++ cfgrtl.c(working copy)
> @@ -1024,13 +1024,20 @@ patch_jump_insn (rtx
On 10/15/11 16:21, Eric Botcazou wrote:
>> PR middle-end/50496
>> * cfgrtl.c (try_redirect_by_replacing_jump): Treat EXIT_BLOCK_PTR case
>> separately before call to redirect_jump(). Add assertion.
>> (patch_jump_insn): Same.
>
> This will definitely disable redirections to the
> gcc/
> * reload1.c (reload_regs_reach_end_p): Replace with...
> (reload_reg_rtx_reaches_end_p): ...this function.
> (new_spill_reg_store): Update commentary.
> (emit_input_reload_insns): Don't clear new_spill_reg_store here.
> (emit_output_reload_insns): Check reload
On 10/17/11 19:43, Eric Botcazou wrote:
>> Yes. However, in the case that caused the PR, this was attempted with
>> reload_completed == 0, so we cannot generate return patterns anyway and
>> must fail.
>
> OK, but we clean up the CFG after reload is completed (e.g. just before
> emitting the prol
On 10/17/11 14:54, Richard Earnshaw wrote:
> On 14/10/11 14:31, Bernd Schmidt wrote:
>> On 07/13/11 16:03, Richard Earnshaw wrote:
>>>>* config/arm/arm.c (store_multiple_sequence): Avoid cases where
>>>>the base reg is stored iff compiling for Thumb1.
>
On 10/18/11 14:30, Richard Earnshaw wrote:
> Well, if that's the case why do we need to test for Thumb1 at all? And
> why do we only enable write-back for Thumb1? other ISA variants can
> also do that (I know that Thumb1 requires write-back, but it's
> optionally available for the other ISA flavo
On 10/17/11 16:10, Nicola Pero wrote:
>>> I checked the attached patch, test results at
>>> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01377.html
>>>
>>> which are the same as with my suggested patch.
>>>
>>> Ok for the trunk?
>>
>> I probably don't have authority to approve this, but looks O
On 10/19/11 23:24, Mike Stump wrote:
> So while tracking down a hairy address reload for an output reload
> bug, copyprop_hardreg_forward_1 was faulting because it was trying to
> extract move patterns that didn't work out, and when it came back to
> the code, it then tries to access recog_data, bu
On 10/21/11 15:42, Bernd Schmidt wrote:
> On 10/14/11 17:35, Vladimir Makarov wrote:
>> The scheduler part of the patch is ok for me (other part changes are
>> obvious). Could you only commit it at the beginning of the next week.
>
> I've committed this variant. It
On 10/03/11 17:52, Paul Brook wrote:
> The C6XABI defined persoality routines ID 3 and 4 use a single 24-bit block
> word of unwinding data. Patch below makes sure this is preserved, rather
> than
> treating it as a set of unwinding opcode bytes.
>
> I seem to have lost this bit of code when I
On 10/03/11 17:57, Paul Brook wrote:
> 2011-10-03 Paul Brook
>
> * config/c6x/c6x.c (c6x_asm_emit_except_personality,
> c6x_asm_init_sections): New functions.
> (TARGET_ASM_EMIT_EXCEPT_PERSONALITY, TARGET_ASM_INIT_SECTIONS):
> Define.
This was also never applied. I've c
On 10/21/11 20:38, Bernd Schmidt wrote:
> On 10/21/11 15:42, Bernd Schmidt wrote:
>> On 10/14/11 17:35, Vladimir Makarov wrote:
>>> The scheduler part of the patch is ok for me (other part changes are
>>> obvious). Could you only commit it at the beginning of the next
The PR uses -fshrink-wrap as the only option, no -Ox. We crash because
shrink-wrapping expects return insns to be generated later on, and that
code is guarded with if (optimize).
Committed the following as obvious after bootstrapping on i686-linux.
Bernd
On 10/24/11 20:02, Chung-Lin Tang wrote:
> On 2011/10/18 04:03 PM, Eric Botcazou wrote:
>>> thread_prologue_and_epilogue_insns should detect all cases where a
>>> return insn can be created. So any CFG cleanup that runs before it does
>>> not need this functionality.
>>
>> So we're left with CFG cl
On 10/22/11 00:43, Mike Stump wrote:
> Index: reload.c
> ===
> --- reload.c (revision 180265)
> +++ reload.c (working copy)
> @@ -7231,7 +7231,7 @@ regno_clobbered_p (unsigned int regno, r
> {
> rtx elt = XVECEXP (PATTE
(working copy)
@@ -1,3 +1,8 @@
+2011-10-25 Bernd Schmidt
+
+ * config/c6x/pr-support.c (__gnu_unwind_24bit): Correct logic for the
+ case where B3 isn't the return register.
+
2011-10-25 Andreas Tobler
* config/rs6000/t-freebsd: Add wildcard.
Index: libgcc/config/c
On 10/26/11 14:27, Alan Modra wrote:
> Committed revision 180522. It turns out that shrink-wrapping isn't as
> effective as it used to be with the 20110915 based sources I was using
> originally. povray Ray_In_Bound no longer gets the benefit of shrink
> wrap, likely due to some cfg optimization.
On 10/26/11 15:54, Alan Modra wrote:
> On Wed, Oct 26, 2011 at 03:01:01PM +0200, Bernd Schmidt wrote:
>> On 10/26/11 14:27, Alan Modra wrote:
>>> Committed revision 180522. It turns out that shrink-wrapping isn't as
>>> effective as it used to be with the 20
When we try to predicate an insn in the scheduler, we must check whether
the condition has been overwritten. The current code for that tries to
look for an insn writing the condition register, then checking
REG_DEP_TRUE deps. It fails in a situation as follows:
[A1] branch
A1:A0 = some operation
s
This fixes a few warnings when building c6x.c. Committed.
Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 180564)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2011-10-24 Bernd Schmidt
On 10/31/11 10:11, Eric Botcazou wrote:
>> I'm suggesting a new patch, as attached. Before reload_completed, we
>> directly return 0 upon nlabel == NULL, which should be identical with
>> old behavior, while asserting fail if after reload (where we assume the
>> simple_return/return distinction is
On 11/02/11 21:13, Hans-Peter Nilsson wrote:
> For big changes such as this, please test on a cross
> configuration as well.
>
> For cris-elf, a patch in the range 180770:180778 supposedly
> yours, cause massive testsuite failures on the form of not
> finding functions in libgcc at link-time. Fro
On 11/03/11 14:12, Rainer Orth wrote:
> Bernd Schmidt writes:
>
>> c6x-elf cross builds are also broken with failures in libgcc/. Rainer,
>> can you investigate?
>
> Can you provide details? It probably would take quite some time for me
> to set up a full cross env
On 11/03/11 18:01, Rainer Orth wrote:
> Bernd Schmidt writes:
>> A cross environment for -elf targets typicaly just requires building up
>> binutils/newlib, and that should be rather quick to set up. A set of
>
> Maybe in theory, but for the case at hand, a c6x-elf configur
On 11/03/11 19:12, Rainer Orth wrote:
> Bernd Schmidt writes:
>
> [Trimming the Cc: list.]
>
>> On 11/03/11 18:01, Rainer Orth wrote:
>>> Bernd Schmidt writes:
>>>> A cross environment for -elf targets typicaly just requires building up
>>>>
On 11/03/11 20:20, Rainer Orth wrote:
> Here's the patch I've come up with. Should I commit it now or would you
> like to do a full testsuite run first?
Please commit, thanks.
Bernd
On 11/03/11 20:20, Rainer Orth wrote:
>
> * config/c6x/t-elf (LIB2ADDEH): Set.
> * config/c6x/t-c6x-elf: Remove.
It builds now, but parts of libgcc are missing. There's no sign of
muldf3, for examples.
Bernd
Ping. Ensure we don't predicate insns with the wrong condition in a
branch delay slot:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02447.html
Bernd
On 11/07/11 19:15, Rainer Orth wrote:
>
> * config/c6x/t-elf (LIB2ADD): Add instead of assigning.
It does seem happier that way, please install. Please also check the
list of files Paolo generated.
Bernd
On 10/28/11 18:06, Ulrich Weigand wrote:
>
> The following patch still needs maintainer review:
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01874.html
Looks straightforward to me. OK.
Bernd
Ping^2. Better support for nested if-then-else structures:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01935.html
>
>
> Bernd
>
On 11/09/11 16:32, Jakub Jelinek wrote:
> --- gcc/combine.c.jj 2011-11-08 23:35:12.0 +0100
> +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> @@ -11397,9 +11397,12 @@ simplify_comparison (enum rtx_code code,
>later on, and then we wouldn't know whether to sign- or
>
On 11/09/11 17:24, Jakub Jelinek wrote:
> --- gcc/combine.c.jj 2011-11-08 23:35:12.0 +0100
> +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> @@ -11397,13 +11397,20 @@ simplify_comparison (enum rtx_code code,
>later on, and then we wouldn't know whether to sign- or
>
On 11/10/11 13:14, Richard Guenther wrote:
> Fair enough. You can count me as "one" then, and I'll defer to Bernd
> to either provide a fix or ack the revert.
I'm trying to track it down.
In 189r.outof_cfglayout, we have
(insn 31 33 35 3 (use (reg/i:SI 0 r0))
../../../../baseline-trunk/libstdc+
On 11/09/11 18:12, Jakub Jelinek wrote:
> So here is hopefully last iteration of that.
>
> Negative constants that trunc_int_for_mode to the same value
> are IMHO just fine too, similarly for ZERO_EXTEND 0x for HImode
> should be fine too. On the other side, if mode is DImode and
> outer mode
On 11/11/11 16:30, Joey Ye wrote:
> -fstrict-volatile-bitfields doesn't work incorrectly in some cases
> when storing into a volatile bit-field.
>
> Bernd provided a fix here about 1 year ago:
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
> But it is pending to trunk. Here are my hu
On 10/31/11 14:24, Henderson, Stuart wrote:
>> 2011-09-26 Jakub Jelinek
>>
>> * rtl.h (const_tiny_rtx): Change into array of 4 x MAX_MACHINE_MODE
>> from 3 x MAX_MACHINE_MODE.
>> (CONSTM1_RTX): Define.
>> * emit-rtl.c (const_tiny_rtx): Change into array of 4 x
>> MAX_MAC
ng treated as
> errors
> make[3]: *** [reload1.o] Error 1
Fixed.
Bernd
Index: gcc/ChangeLog
===========
--- gcc/ChangeLog (revision 190317)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-08-11
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much of a
difference in any macro benchmarks.
Bootstrapped and tested on x86_64-linux and also tested
On 08/03/2012 02:05 PM, Bernd Schmidt wrote:
> This patch allows us to change
>
> rn++
> rm=[rn]
>
> into
>
> rm=[rn + 4]
> rn++
Ping.
Bernd
On 09/17/2012 07:32 PM, Ulrich Weigand wrote:
> In any case, the change in the condition you noticed was introduced by a
> recent
> patch by Bernd: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00171.html
>
> It seems that we ought to use a similar test to what Bernd introduced in
> gen_reload, th
On 09/20/2012 07:42 PM, H.J. Lu wrote:
> On Fri, Aug 3, 2012 at 5:05 AM, Bernd Schmidt wrote:
>> This patch allows us to change
>>
>> rn++
>> rm=[rn]
>>
>> into
>>
>> rm=[rn + 4]
>> rn++
>>
> This caused:
>
> http://gcc.gn
On 06/27/2012 10:45 AM, Richard Guenther wrote:
> On Wed, Jun 27, 2012 at 5:02 AM, Richard Henderson wrote:
>> sometimes not (increased code size):
>>
>> -: 41 bd 01 00 00 00 mov$0x1,%r13d
>> -: 4d 89 ecmov%r13,%r12
>> +: 41 bc 01 00 00 00 mov
We're moving a load across a call since we don't recognize calls as
memory-clobbering.
Bootstrapping and testing now on 4.7 x86_64-linux, ok everywhere?
Bernd
PR rtl-optimization/53908
* df-problems.c (can_move_insns_across): Calls can clobber memory.
Index: gcc/df-problems.c
On 03/26/2012 06:03 PM, Andreas Schwab wrote:
> Bernd Schmidt writes:
>
>> Does 4.7 still have the failure at all?
>
> Yes, see PR52573.
Well, I still think having both REG_DEAD and REG_UNUSED for the same reg
is bogus, but fixing that causes trouble in reg-stack. It seems
On 07/12/2012 12:10 AM, Steven Bosscher wrote:
> On Wed, Jul 11, 2012 at 11:31 PM, Bernd Schmidt
> wrote:
>> On 03/26/2012 06:03 PM, Andreas Schwab wrote:
>>> Bernd Schmidt writes:
>>>
>>>> Does 4.7 still have the failure at all?
>>>
>>
There are a number of problems in the interaction between secondary
memory and subregs. If we reload the inner of a subreg, we forget about
this when deciding whether to use secondary memory, and just use
REGNO_REG_CLASS on the (now reloaded) inner.
Also, we don't really know what to do if we get
On 08/03/2012 08:50 PM, Uros Bizjak wrote:
> Hello!
>
>> Bootstrapped and tested on i686-linux. It's also been in several of our
>> internal trees, going back to even 4.4-based ones IIRC, and has had
>> testing for several architectures. Ok for the i386 part? I intend to
>> check the reload bits i
revision 186874)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-04-26 Bernd Schmidt
+
+ * PR middle-end/52997
+ * ira.c (find_moveable_pseudos): Call resize_reg_info.
+
2012-04-26 David S. Miller
* config/sparc/niagara4.md: New fil
On 04/27/2012 06:25 PM, Ulrich Weigand wrote:
Bernd Schmidt wrote:
We're creating new pseudos, and while we're resizing some data
structures, we aren't doing it for everything.
@@ -3983,7 +3983,8 @@ find_moveable_pseudos (void)
last_moveable_pseud
This patch allows us to recognize that even if the argument to memcpy
lives across the call, we can allocate it to a call-used register by
reusing the return value of the function.
First, the patch sets the existing "fn spec" attribute for
memcpy/memmove. This is translated to a new form of
C
On 05/02/2012 11:10 AM, Richard Guenther wrote:
On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidt wrote:
This patch allows us to recognize that even if the argument to memcpy lives
across the call, we can allocate it to a call-used register by reusing the
return value of the function.
Heh
On 05/03/2012 07:47 PM, Richard Sandiford wrote:
Richard Guenther writes:
On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidt wrote:
This patch allows us to recognize that even if the argument to memcpy lives
across the call, we can allocate it to a call-used register by reusing the
return value
ter parameter(s) are all nonnull. */
DEF_ATTR_TREE_LIST (ATTR_CONST_NOTHROW_NONNULL_LEAF, ATTR_CONST, ATTR_NULL, \
ATTR_NOTHROW_NONNULL_LEAF)
Index: gcc/ChangeLog
=======
--- gcc/ChangeLog (revision 187454)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,50 @@
+2012-05-14 Bernd Schmidt
+
+ * attr
1701 - 1800 of 2198 matches
Mail list logo
