> -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 * conve
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 is
> -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: [P
cpplib-4.8-b20130224.ja.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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, 'cpplib-4.8-b2013022
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:
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.
>
> Bo
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 Ja
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
>
> PR middl
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 a
On Fri, Mar 1, 2013 at 3:56 PM, Eric Botcazou 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 for this becaus
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.
>
> --- gcc
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 : 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:
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 m
2013/3/4 Georg-Johann Lay :
> 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
> shifte
On Fri, 1 Mar 2013 14:35:05 +
Paul Brook 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 been starin
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) t
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 wit
> > > 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
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 re
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 sin
On 02/10/2013 10:40 PM, David Holsgrove wrote:
Setup stack protection at entry.
libgcc/Changelog
2013-02-11 Edgar E. Iglesias
* config/microblaze/crti.S: Setup stack protection at entry
Committed revision 196432.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94
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
* config/microblaze/predic
On Mon, 4 Mar 2013 13:08:57 +
Paul Brook 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 planning to
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
* config/microblaze/microblaze.c
(microblaze_valid_pic_const): New function
(microblaze_legitimate_p
> 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
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. Given
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 no
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 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
> decide they hav
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? Thanks
"Moore, Catherine" 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 have any comments on th
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 opts-common.o
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 Jaku
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,
bootstrappe
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 i686-linux,
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
PR middle-end/56461
* tree-vect-slp.c (vect_supported_load_permutation_p): Free
[Sorry Jakub, mid-air collision. I just posted this comment to the PR.]
Jakub Jelinek 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 (truncate:C X
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
* c-pretty-print.c (pp_c_
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, bootst
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 (reg_kn
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
PR middle-end/56461
*
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 "if"s.
So like this instead?
2013-03-04 Jakub Jel
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 Jak
Jakub Jelinek 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 "if"s.
>
> So like this
On Mon, Mar 4, 2013 at 3:11 PM, Jakub Jelinek 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 and clears
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" writes:
> > Hi R
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
* config/mips/micromips.md (mips_jraddiusp): New insn.
* config/mips/mips.c (mips_expand_epilogue): Gene
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.g
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/gc
> 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 possib
On Mon, 4 Mar 2013, Jakub Jelinek wrote:
> 2013-03-04 Jakub Jelinek
>
> 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 Taylo
On Mon, Mar 4, 2013 at 4:11 PM, Mike Frysinger 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 Frysinger wrote
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 f
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
