-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Monday, March 04, 2013 00:49
To: Joey Ye
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] Fix PR50293 - LTO plugin with space in path
On Mon, 18 Feb 2013, Joey Ye wrote:
+static char *
Ping?
Thanks!
-Zhenqiang
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
Sent: Friday, January 11, 2013 5:21 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH libgcc] Fix ARM uclinux libgcc config order issue
-Original Message-
From: Georg-Johann Lay [mailto:g...@gcc.gnu.org]
Sent: Monday, March 04, 2013 02:42
To: Joey Ye
Cc: 'Joseph Myers'; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix PR50293 - LTO plugin with space in path
Joey Ye schrieb:
Ping
Subject: RE: [PATCH] Fix
cpplib-4.8-b20130224.ja.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
coordina...@translationproject.org
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Japanese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/ja.po
(This file,
On 03/04/2013 05:56 AM, Ulrich Drepper wrote:
I'd like to check in this patch which would improve the performance of
the distribution quite a bit by pulling constant computations into the
constructor. This patch will change the memory layout which can be
done easily only now. It also fixes one
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
Hi!
This fixes leaks like
==31176== 176 bytes in 2 blocks are definitely lost in loss record 432 of 541
==31176==at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31176==by 0x114DF6F: xrealloc (xmalloc.c:177)
==31176==by 0x85E0AA: void
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
Hi!
Except for the case when we set vec_oprnd1 to non-NULL, with j == 0
we always initialize vec_oprnds[01] with vect_get_vec_defs, which overwrites
the vectors rather than just filling them. So we shouldn't allocate the
vectors first.
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
Hi!
For the modifier == NONE !slp_node case we call vect_get_vec_defs, so
we overwrite vec_oprnds0, thus we shouldn't allocate it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2013-03-01 Jakub
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
Hi!
When merging partitions together, we remove them from partitions vector,
thus don't free them at all. Fixed thusly, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2013-03-01 Jakub Jelinek
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
Hi!
path vector has been only released when return false; later in the function,
but not in this case. Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2013-03-01 Jakub Jelinek ja...@redhat.com
On Fri, 1 Mar 2013, Jakub Jelinek wrote:
Hi!
The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies 1, we'd leak the result_chain vector too.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
On Fri, Mar 1, 2013 at 3:56 PM, Eric Botcazou ebotca...@adacore.com wrote:
But in theory this pessimizes code as aggregate_value_p returned true
for this? That is, isn't the bug that we rewrite a possible
return-slot-decl into SSA? (do we do that here?)
Yes, aggregate_value_p returns true
http://gcc.gnu.org/r196428
Fixed this test case that assumed int is always 32 bits at least.
PR testsuite/52641
PR tree-optimization/52631
* gcc.dg/tree-ssa/pr52631.c: Fix 16-bit int.
Johann
Index: gcc.dg/tree-ssa/pr52631.c
On Mon, Mar 04, 2013 at 12:15:31PM +0100, Georg-Johann Lay wrote:
http://gcc.gnu.org/r196428
Fixed this test case that assumed int is always 32 bits at least.
PR testsuite/52641
PR tree-optimization/52631
* gcc.dg/tree-ssa/pr52631.c: Fix 16-bit int.
---
http://gcc.gnu.org/r196429
gcc.dg/pr55153.c needs targets with scheduling, thus dg-require it.
gcc.dg/pr56228.c will fail on AVR, thus skip it there:
* gcc.dg/pr55153.c: Add dg-require-effective-target scheduling.
* gcc.dg/pr56228.c avr: Skip.
--
Index: gcc.dg/pr55153.c
Jakub Jelinek wrote:
On Mon, Mar 04, 2013 at 12:15:31PM +0100, Georg-Johann Lay wrote:
http://gcc.gnu.org/r196428
Fixed this test case that assumed int is always 32 bits at least.
PR testsuite/52641
PR tree-optimization/52631
* gcc.dg/tree-ssa/pr52631.c: Fix 16-bit
This patch fixed the speed of 64-bit shifts and rotate.
These operations were implemented by bit-wise shifts and thus the speed is not
reasonable for such basic arithmetic.
The new implementation first shifts byte-wise and only the remaining mod 8 is
shifted bit-wise.
The new methods needs few
2013/3/4 Georg-Johann Lay a...@gjlay.de:
This patch fixed the speed of 64-bit shifts and rotate.
These operations were implemented by bit-wise shifts and thus the speed is not
reasonable for such basic arithmetic.
The new implementation first shifts byte-wise and only the remaining mod 8 is
On Fri, 1 Mar 2013 14:35:05 +
Paul Brook p...@codesourcery.com wrote:
It's not even necessary to use explicit shuffles -- NEON has
perfectly good instructions for loading/storing vectors in the
right order, in the form of vld1 vst1. I'm afraid the solution
to this problem might have
On Fri, Mar 01, 2013 at 09:16:16PM +0100, Jakub Jelinek wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, tested also with
valgrind checking on various testcases (full --enable-checking=yes,valgrind
bootstrap queued for the weekend).
FYI, with this patch (first time I remember) the
When inlining call stmts with a NULL gimple_block we still remap
all the callee blocks into a block tree copy but we'll end up
not referencing it from anywhere. This causes verification failures
because then we have nothing refering to the inline stmt blocks.
This seems to be an issue mostly
I can't exactly remember why we didn't do that to start with. I
think the problem was ABI-related, or to do with transferring NEON
vectors to/from ARM registers when it was necessary to do that...
I'm planning to do some archaeology to try to see if I can figure
out a definitive
On Mon, Mar 04, 2013 at 01:42:51PM +0100, Richard Biener wrote:
When inlining call stmts with a NULL gimple_block we still remap
all the callee blocks into a block tree copy but we'll end up
not referencing it from anywhere. This causes verification failures
because then we have nothing
This fixes PR56270 - when two SLP instances share a load
we fail to properly initialize the vectorized SLP stmts.
In fact, there is no support in SLP to share vectorized
code between instances - the only support that's explicitely
wired in is to have different permutations of a load inside
a
On 02/10/2013 10:40 PM, David Holsgrove wrote:
Setup stack protection at entry.
libgcc/Changelog
2013-02-11 Edgar E. Iglesias edgar.igles...@gmail.com
* config/microblaze/crti.S: Setup stack protection at entry
Committed revision 196432.
--
Michael Eagerea...@eagercon.com
1960
On 02/10/2013 10:40 PM, David Holsgrove wrote:
Dont allow unsupported target rtx into call_internal1
Fix it by adding a simplified call_insn_operand, call_insn_simple_operand
that only accepts the supported rtx code types.
Changelog
2013-02-11 Edgar E. Iglesias edgar.igles...@gmail.com
*
On Mon, 4 Mar 2013 13:08:57 +
Paul Brook p...@codesourcery.com wrote:
I can't exactly remember why we didn't do that to start with. I
think the problem was ABI-related, or to do with transferring
NEON vectors to/from ARM registers when it was necessary to do
that... I'm
On 02/10/2013 10:40 PM, David Holsgrove wrote:
Add microblaze_legitimate_pic_operand method
Prevents ICE where insn contains an invalid address
Changelog
2013-02-11 David Holsgrove david.holsgr...@xilinx.com
* config/microblaze/microblaze.c
(microblaze_valid_pic_const): New function
On Mon, Mar 04, 2013 at 01:42:51PM +0100, Richard Biener wrote:
When inlining call stmts with a NULL gimple_block we still remap
all the callee blocks into a block tree copy but we'll end up
not referencing it from anywhere. This causes verification failures
because then we have nothing
Hi,
today I have noticed that get_or_create_ssa_default_def passes its
struct function parameter to ssa_default_def but then happily uses a
cfun-only make_ssa_name and even explicitely passes cfun to
set_ssa_default_def. Fixed with the patch below.
Bootstrapped and tested on x86_64-linux.
Within an non-static data member initializer, the 'this' declaration is
just a placeholder to be replaced when the NSDMI is used in a
constructor, there's no function to find it in. So we need to handle it
specially for implicit capture.
This patch also fixes 54383, the case where there is
On Mon, Mar 04, 2013 at 06:11:24PM +0100, Martin Jambor wrote:
today I have noticed that get_or_create_ssa_default_def passes its
struct function parameter to ssa_default_def but then happily uses a
cfun-only make_ssa_name and even explicitely passes cfun to
set_ssa_default_def. Fixed with
On Mon, 4 Mar 2013 15:29:22 +
Julian Brown jul...@codesourcery.com wrote:
Remember that it's not just function arguments, it's any interface
shared between functions. i.e. including structures and global
variables.
Ugh, I hadn't considered structures or global variables :-/. If we
Hello,
Bug c++/55135 is another one of those almost-insane large test cases
that triggers some of the worst time complexity behavior GCC has to
offer. The attached patch doesn't actually fix anything the bug poster
complained about, but something I ran into myself while trying to
compile the file
Hi Richard,
I've attached an example patch for the add pattern that tries to identify the
short microMIPS variants. In your last review, you mentioned that you would
like to see the register requirements modeled in the patterns. Do you have any
comments on the approach that I'm taking?
Moore, Catherine catherine_mo...@mentor.com writes:
Hi Richard,
I've attached an example patch for the add pattern that tries to
identify the short microMIPS variants. In your last review, you
mentioned that you would like to see the register requirements modeled
in the patterns. Do you
Hi!
gnattools apparently link in parts of libtarget* without linking against
libstdc++/libsupc++, so my recent change where opts.o has been brought in
on powerpc when before only opts-common.o has been linked in caused
a bootstrap regression.
Fixed by moving opts_{obstack,concat} to
Hi!
Optimizing (truncate:A (subreg:B (truncate:C X) 0)) into
(truncate:A X) is wrong if C mode is narrower than A mode.
The following patch fixes that and simplifies it into
(subreg:A (truncate:C X 0)) instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-03-04
Hi!
vect_create_epilog_for_reduction leaks memory both from the inner_phis
vector not being released for double_reduc, and also for stmt_vec_info
it creates (because those are added for stmts added into exit_bb, i.e.
after loop, which destroy_loop_vec_info doesn't free). Fixed thusly,
Hi!
This function was releasing only some vectors pushed into queues vector, not
all, and wasn't releasing bounds vector. Fixed thusly. There is no need to
use a typedef for the C++ish vec.h vectors, and the code can be tiny bit
simplified.
Bootstrapped/regtested on x86_64-linux and
Hi!
When returning true, load_index sbitmap is released, but not when returning
false. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-03-04 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* tree-vect-slp.c
[Sorry Jakub, mid-air collision. I just posted this comment to the PR.]
Jakub Jelinek ja...@redhat.com writes:
Optimizing (truncate:A (subreg:B (truncate:C X) 0)) into
(truncate:A X) is wrong if C mode is narrower than A mode.
The following patch fixes that and simplifies it into
(subreg:A
Hi!
This is something that caused a lot of testsuite failures during my
--enable-checking=yes,valgrind bootstrap. Nothing was initializing
pp-flags. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2013-03-04 Jakub Jelinek ja...@redhat.com
*
Hi!
maybe_unwind_expanded_macro_loc now calls diagnostic_append_node
in two places, but often with non-NULL pp_get_prefix (context-printer).
diagnostic_append_node overwrites it with a new value, then frees that
new value and clears it, but that means we leak the old prefix.
Fixed thusly,
Hi!
Something that again hits lots of testcases during valgrind checking
bootstrap. init_alias_analysis apparently does
vec_safe_grow_cleared (reg_known_value, maxreg - FIRST_PSEUDO_REGISTER);
reg_known_equiv_p = sbitmap_alloc (maxreg - FIRST_PSEUDO_REGISTER);
but doesn't bitmap_clear
Hi!
alloc_succs_info creates vectors up to and including
succs_info_pool.max_top, so without the following fix we leak the
last set of 3 vectors.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-03-04 Jakub Jelinek ja...@redhat.com
PR
Hi!
As reported by valgrind, cp_parser_braced_list doesn't initialize
*non_constant_p when seeing just {}, and thus when e.g. cp_parser_condition
calls it, non_constant_p is uninitialized when cp_finish_decl
is called with !non_constant_p.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
On Mon, Mar 04, 2013 at 09:08:36PM +, Richard Sandiford wrote:
...truncations can't be to a narrower mode (already asserted at the top
of the function) so in some ways I think it would be clearer to have an
if ... else rather than two ifs.
So like this instead?
2013-03-04 Jakub Jelinek
On 03/04/2013 02:08 PM, Jakub Jelinek wrote:
Hi!
This is something that caused a lot of testsuite failures during my
--enable-checking=yes,valgrind bootstrap. Nothing was initializing
pp-flags. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2013-03-04
Jakub Jelinek ja...@redhat.com writes:
On Mon, Mar 04, 2013 at 09:08:36PM +, Richard Sandiford wrote:
...truncations can't be to a narrower mode (already asserted at the top
of the function) so in some ways I think it would be clearer to have an
if ... else rather than two ifs.
So like
On Mon, Mar 4, 2013 at 3:11 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
maybe_unwind_expanded_macro_loc now calls diagnostic_append_node
in two places, but often with non-NULL pp_get_prefix (context-printer).
diagnostic_append_node overwrites it with a new value, then frees that
new value
On Mon, Mar 4, 2013 at 10:17 PM, Jakub Jelinek wrote:
Hi!
Something that again hits lots of testcases during valgrind checking
bootstrap. init_alias_analysis apparently does
vec_safe_grow_cleared (reg_known_value, maxreg - FIRST_PSEUDO_REGISTER);
reg_known_equiv_p = sbitmap_alloc
On Mon, Mar 04, 2013 at 11:17:41PM +0100, Steven Bosscher wrote:
On Mon, Mar 4, 2013 at 10:17 PM, Jakub Jelinek wrote:
Something that again hits lots of testcases during valgrind checking
bootstrap. init_alias_analysis apparently does
vec_safe_grow_cleared (reg_known_value, maxreg -
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: Monday, March 04, 2013 3:54 PM
To: Moore, Catherine
Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
Moore, Catherine catherine_mo...@mentor.com
Hi Richard,
This patch adds support for the microMIPS jraddiusp instruction to the base
microMIPS base.
Is this okay to commit?
Thanks,
Catherine
2013-03-04 Catherine Moore c...@codesourcery.com
* config/mips/micromips.md (mips_jraddiusp): New insn.
* config/mips/mips.c
Hi,
On Mon, 2013-03-04 at 15:55 +0900, Yoshinori Sato wrote:
It function called to divide operator.
But libgcc.a is not include it helper functions.
This patch is included those functions.
diff -ru gcc-4.7.2.org/gcc/config.gcc gcc-4.7.2/gcc/config.gcc
--- gcc-4.7.2.org/gcc/config.gcc
On Tue, 2013-03-05 at 00:15 +0100, Oleg Endo wrote:
Hi,
On Mon, 2013-03-04 at 15:55 +0900, Yoshinori Sato wrote:
It function called to divide operator.
But libgcc.a is not include it helper functions.
This patch is included those functions.
diff -ru gcc-4.7.2.org/gcc/config.gcc
I somehow missed the Appendix A: Support for Advanced SIMD Extensions
in the AAPCS document (it's not in the TOC!). It looks like the
builtin vector types are indeed defined to be stored in memory in
vldm/vstm order -- I think that means we're back to square one.
There's still the possibility
On Mon, 4 Mar 2013, Jakub Jelinek wrote:
2013-03-04 Jakub Jelinek ja...@redhat.com
PR bootstrap/56509
* opts.c (opts_obstack, opts_concat): Moved to...
* opts-common.c (opts_obstack, opts_concat): ... here.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Saturday 26 January 2013 21:40:44 Ian Lance Taylor wrote:
On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote:
On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote:
On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote:
On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote:
On Mon, Mar 4, 2013 at 4:11 PM, Mike Frysinger vap...@gentoo.org wrote:
On Saturday 26 January 2013 21:40:44 Ian Lance Taylor wrote:
On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote:
On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote:
On Tue, Jan 15, 2013 at 9:45 AM, Mike
Hi Jakub,
On 2013-03-05 01:20, Jakub Jelinek wrote:
Hi!
alloc_succs_info creates vectors up to and including
succs_info_pool.max_top, so without the following fix we leak the
last set of 3 vectors.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for
trunk?
This is
Hi!
This patch syncs the list of target exp files (a few have been added in the
last few years). Also, in my testing, usually vect.exp, guality.exp,
struct-layout-1.exp and i386.exp take quite a lot of time, so it is
undesirable to have them in pairs anymore, so the patch allows running all 4
of
64 matches
Mail list logo
