The libquadmath/quadmath.h file cannot be used with C++. The
following patch allows inclusion and use of the quadmath.h header
file.
2013-03-06 Shakthi Kannan
PR libquadmath/55473
* quadmath.h: Add ifdef __cplusplus macros.
---
libquadmath/quadmath.h | 8
1 file changed, 8 ins
On Tue, Mar 05, 2013 at 11:58:09PM -0500, Vladimir Makarov wrote:
> I don't see any harm from your patch but I guess it should be fixed
> by clearing reg_know_equiv_p. I think you need Steven's opinion on
> this as he is an author of the code.
Yeah, I've already committed the clearing of the sbit
On 13-03-04 4: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 (maxreg - FIRST_PSEU
On Mon, 4 Mar 2013, Joey Ye wrote:
> + char *new_spec = (char *)xmalloc (len + number_of_space + 1);
Space in cast between "(char *)" and "xmalloc". OK with that change.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 1 Mar 2013, Tobias Burnus wrote:
> Joseph S. Myers wrote:
> > OK, though for the libiberty patch it would be good if someone can find
> > the make-obstacks-texi.sh script referred to in libiberty.texi, check it
> > in and get obstacks.texi exactly in sync with the output of that script
> >
Hi,
This is the patch that I posted in the PR and that was pre-approved by
Kaz, with some documentation bits added.
Tested with 'make info dvi pdf' and 'make all'.
Applied as revision 196484.
Will backport it to 4.7 branch.
Cheers,
Oleg
gcc/ChangeLog:
PR target/56529
* config/s
Oleg Endo wrote:
> OK for 4.8 trunk or 4.9? :)
Sorry, I've missed the trunk part. OK for 4.9.
Regards,
kaz
This patch fixes an ICE in remove_addr_table_entry, where we try to
remove the .debug_addr entries for an expression where they've already
been removed earlier in the loop.
-cary
2013-03-05 Sterling Augustine
Cary Coutant
PR debug/55364
* gcc/dwarf2out.c (reso
On Wed, 2013-03-06 at 07:37 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > This adds basic support for the SH2A clips and clipu instructions.
> > Tested on rev 196406 with
> > make -k check RUNTESTFLAGS="--target_board=sh-sim
> > \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
> >
On Tue, Mar 05, 2013 at 02:40:34PM -0700, Jeff Law wrote:
> So it's not that cselib (and possibly others) can't handle these
> complex RTL expressions, it's just unbearably slow. Right?
They handle it, but with bad compile time complexity, so on some testcases
it might take years or centuries etc
Oleg Endo wrote:
> This adds basic support for the SH2A clips and clipu instructions.
> Tested on rev 196406 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no new failures.
>
> OK for trunk or 4.9?
OK.
Regards,
On Tue, Mar 05, 2013 at 11:03:13PM +0100, Jakub Jelinek wrote:
> > ifcvt.c tests only small_register_classes_for_mode_p in the other places,
> > so
> > do you really need class_likely_spilled_p here?
>
> I guess I don't. I've grepped for small_register_classes_for_mode_p and
> didn't see
> any
Darwin does PIC differently than ELF so that the scan-assembler-times
fails for g++.dg/debug/dwarf2/thunk1.C. The attached patch skips the
scan-assembler for *-*-darwin*. Tested on x86_64-apple-darwin12. Okay
for gcc trunk.
Jack
gcc/testsuite/
2013-03-05 Jack Howarth
On Tue, Mar 05, 2013 at 06:28:13PM +0100, Eric Botcazou wrote:
> > Without this patch, ifcvt extends lifetime of %eax hard register,
> > which causes reload/LRA ICE later on. Combiner and other passes try hard
> > not to do that, even ifcvt has code for it if x is a hard register a few
> > lines b
On 03/05/2013 09:30 AM, Jakub Jelinek wrote:
Hi!
cselib (probably among others) isn't prepared to handle arbitrarily
complex debug insns. The debug insns are usually created from debug stmts
which shouldn't have unbound complexity, but with TER we can actually end up
with arbitrarily large debu
"Moore, Catherine" writes:
> Index: config/mips/micromips.md
> ===
> --- config/mips/micromips.md (revision 196341)
> +++ config/mips/micromips.md (working copy)
> @@ -95,6 +95,19 @@
> (set_attr "mode" "SI")
> (set_attr "can
"Moore, Catherine" writes:
>> -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
>>
>> "M
Hi,
This adds basic support for the SH2A clips and clipu instructions.
Tested on rev 196406 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK for trunk or 4.9?
Cheers,
Oleg
gcc/ChangeLog:
PR ta
On 03/05/2013 07:09 AM, David Holsgrove wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Wednesday, 27 February 2013 4:12 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Michael Eager (ea...@eagercon.com); John
Williams; Edgar E. Iglesias (ed
Looks good.
thanks,
David
On Tue, Mar 5, 2013 at 11:06 AM, Rong Xu wrote:
> Hi,
>
> This patch changes the default lipo module grouping
> algorithm from algoritm 0 (eager propagation algorithm)
> to algorith 1 (inclusion_based priority algorithm).
>
> It also changes the name __gcov_lipo_strict
Hi,
This patch changes the default lipo module grouping
algorithm from algoritm 0 (eager propagation algorithm)
to algorith 1 (inclusion_based priority algorithm).
It also changes the name __gcov_lipo_strict_inclusion
to __gcov_lipo_weak_inclusion and the default is 0.
Tested with google interna
Hi All,
This patch fixes a minor annoyance that causes backtraces to disappear
inside of aeabi_ldivmod and aeabi_uldivmod due to the lack of appropriate
DWARF information. I fixed the problem by adding the necessary cfi_*
macros in these functions.
OK?
2013-03-05 Meador Inge
* confi
On 03/05/2013 09:31 AM, Kai Tietz wrote:
> 2013-03-05 Kai Tietz
>
> * sdbout.c (sdbout_one_type): Switch to current function's section
> supporting cold/hot.
Ok.
r~
Hello,
this patch fixes a regression in gcc.dg/debug/tls-1.c testcase for -gcoff.
ChangeLog
2013-03-05 Kai Tietz
* sdbout.c (sdbout_one_type): Switch to current function's section
supporting cold/hot.
Tested for x86_64-w64-mingw32. Ok for apply?
Index: sdbout.c
===
> Without this patch, ifcvt extends lifetime of %eax hard register,
> which causes reload/LRA ICE later on. Combiner and other passes try hard
> not to do that, even ifcvt has code for it if x is a hard register a few
> lines below it, but in this case the hard register is SET_SRC (set_b).
>
> Wi
On 03/05/2013 09:26 AM, Jakub Jelinek wrote:
Hi!
Without this patch, ifcvt extends lifetime of %eax hard register,
which causes reload/LRA ICE later on. Combiner and other passes try hard
not to do that, even ifcvt has code for it if x is a hard register a few
lines below it, but in this case t
Hi,
this (and 55786, which is a Dup) is an ICE on invalid regression in
4.7/4.8. The problem is that for such broken input,
check_elaborated_type_specifier is called by
cp_parser_elaborated_type_specifier with a DECL which has a nul
TREE_TYPE, a TEMPLATE_ID_EXPR actually, and therefore immedi
Hi!
cselib (probably among others) isn't prepared to handle arbitrarily
complex debug insns. The debug insns are usually created from debug stmts
which shouldn't have unbound complexity, but with TER we can actually end up
with arbitrarily large debug insns.
This patch fixes that up during expan
Hi!
Without this patch, ifcvt extends lifetime of %eax hard register,
which causes reload/LRA ICE later on. Combiner and other passes try hard
not to do that, even ifcvt has code for it if x is a hard register a few
lines below it, but in this case the hard register is SET_SRC (set_b).
With this
On Fri, Mar 01, 2013 at 09:41:27AM +0100, Richard Biener wrote:
> On Wed, Feb 27, 2013 at 6:38 PM, Joseph S. Myers
> wrote:
> > On Wed, 27 Feb 2013, Richard Biener wrote:
> >
> >> Wouldn't it be better to simply pass this using the variable size handling
> >> code? Thus, initialize args_size.var
On Tue, Mar 5, 2013 at 3:50 PM, Steven Bosscher wrote:
> On Tue, Mar 5, 2013 at 1:32 PM, Richard Biener wrote:
>>> The attached patch is a first stab at an idea I've had for a while:
>>> Implement a "change of view" for bitmaps, such that a bitmap can be
>>> either a linked list, or a binary tree.
On 03/05/2013 06:54 AM, David Holsgrove wrote:
Hi Michal,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Monday, 4 March 2013 3:37 am
To: David Holsgrove
Cc: Michael Eager; gcc-patches@gcc.gnu.org; John Williams; Edgar E. Iglesias
(edgar.igles...@gmail.com); Vino
This fixes PR50494 by avoiding to increase alignment of decls
that are in the constant pool by the vectorizer.
Bootstrap & regtest pending on powerpc64-linux-gnu, with
the older fix reverted.
Richard.
2013-03-05 Richard Biener
PR middle-end/50494
* tree-vect-data-refs.c (vec
On 03/05/2013 08:12 AM, Jakub Jelinek wrote:
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
LRA leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
This patch is ok too.
On 03/05/2013 08:12 AM, Jakub Jelinek wrote:
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
This patch is ok. Thanks for working on this
Hi Michael,
> -Original Message-
> From: Michael Eager [mailto:ea...@eagerm.com]
> Sent: Wednesday, 27 February 2013 4:12 am
> To: David Holsgrove
> Cc: gcc-patches@gcc.gnu.org; Michael Eager (ea...@eagercon.com); John
> Williams; Edgar E. Iglesias (edgar.igles...@gmail.com); Vinod Kathail
On Tue, Mar 5, 2013 at 2:52 AM, Jakub Jelinek wrote:
>
> 2013-03-05 Jakub Jelinek
>
> PR middle-end/56526
> * simple-object-mach-o.c (simple_object_mach_o_segment): Initialize
> wrapper_sect_offset to avoid a warning.
This is OK.
Thanks.
Ian
Hi Michal,
> -Original Message-
> From: Michael Eager [mailto:ea...@eagerm.com]
> Sent: Monday, 4 March 2013 3:37 am
> To: David Holsgrove
> Cc: Michael Eager; gcc-patches@gcc.gnu.org; John Williams; Edgar E. Iglesias
> (edgar.igles...@gmail.com); Vinod Kathail; Vidhumouli Hunsigida; Nagar
On Tue, Mar 5, 2013 at 1:32 PM, Richard Biener wrote:
>> The attached patch is a first stab at an idea I've had for a while:
>> Implement a "change of view" for bitmaps, such that a bitmap can be
>> either a linked list, or a binary tree.
...
> Definitely a nice idea. Iteration should be easy to i
Hi,
On Tue, 5 Mar 2013, Richard Biener wrote:
> > I haven't tested this patch at all, except making sure that it
> > compiles. Just posting this for discussion, and for feedback on the
> > idea. I know there have been many others before me who've tried
> > different data structures for bitmaps
OK.
Jason
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote:
> > On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> > > Thanks for all the recent reviews of memory leak plugging patches,
> > > there are 4 still unreviewed from last week though.
> > >
> > > -
On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote:
> On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> > Thanks for all the recent reviews of memory leak plugging patches,
> > there are 4 still unreviewed from last week though.
> >
> > - sched-deps leak fix:
> > http://gcc.gnu.org/ml/gcc-pat
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> Hi!
>
> Thanks for all the recent reviews of memory leak plugging patches,
> there are 4 still unreviewed from last week though.
>
> - sched-deps leak fix:
> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
>
> - LRA leak fix:
> http://gcc.gnu.o
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
- LRA leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
- libcpp leak fix:
ht
This removes all encouragement to use -fwhole-program with -flto
from the documentation. As can be seen in PR56533 it can be
most confusing ... instead advise to rely on a linker plugin.
Ok?
Thanks,
Richard.
2013-03-05 Richard Biener
* doc/invoke.texi (fwhole-program): Discourage u
On Tue, Mar 5, 2013 at 1:00 PM, Steven Bosscher wrote:
> Hello,
>
> A recurring problem with GCC's sparse bitmap data structure is that it
> performs poorly for random access patterns. Such patterns result in
> linked-list walks, and can trigger behavior quadratic in the number of
> linked-list me
On Tue, Mar 05, 2013 at 12:27:20PM +0100, Richard Biener wrote:
> This should fix PR56525, we reference ggc_freed loop structures
> from bb->loop_father when fix_loop_structure removes a loop
> and then calls flow_loops_find. Fixed by delaying the ggc_free
> part of loop removal until after that (
On Tue, 5 Mar 2013 10:42:59 +0100
Richard Biener wrote:
> On Tue, Mar 5, 2013 at 12:47 AM, Paul Brook
> wrote:
> >> 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 de
On Tue, Mar 05, 2013 at 12:57:41PM +0100, Richard Biener wrote:
> As follows.
>
> Richard.
>
> 2013-03-05 Richard Biener
>
> * tree-ssa-sccvn.c (set_value_id_for_result): For a NULL
> result set a new value-id.
Looks much better.
You forgot to adjust the ChangeLog entry, and PR l
Hi,
the attached patch enables the debug line infos to be generated from
the asm listing for s390. With the patch two testsuite failures
disappear.
< FAIL: gcc.dg/debug/dwarf2/asm-line1.c scan-assembler is_stmt 1
< FAIL: gnat.dg/return3.adb scan-assembler loc 1 6
Committed to mainline.
Bye,
-
> In other words, any 32-bit target with 'need_64bit_hwint=yes' in config.gcc
> is not able to have benefit from this optimization because it never
> passes the condition test.
>
>
> My solution is to use GET_MODE_MASK(mode) to filter out all bits not
> in target mode. The following is my patch:
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
> On Tue, Mar 05, 2013 at 12:51:09PM +0100, Richard Biener wrote:
> > VN now inserts all sorts of calls into the references hashtable,
> > not only those which produce a value. This results in missing
> > initializations of ->value_id which eventually PRE
On Tue, Mar 05, 2013 at 12:51:09PM +0100, Richard Biener wrote:
> VN now inserts all sorts of calls into the references hashtable,
> not only those which produce a value. This results in missing
> initializations of ->value_id which eventually PRE ends up
> accessing.
>
> The following fixes that
VN now inserts all sorts of calls into the references hashtable,
not only those which produce a value. This results in missing
initializations of ->value_id which eventually PRE ends up
accessing.
The following fixes that.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
20
This should fix PR56525, we reference ggc_freed loop structures
from bb->loop_father when fix_loop_structure removes a loop
and then calls flow_loops_find. Fixed by delaying the ggc_free
part of loop removal until after that (I thought about other
ways to fix the reference but they are way more i
Hi,
I added the testcase and closed the PR as fixed in 4.7.3 and mainline.
Paolo.
/
2013-03-05 Paolo Carlini
PR c++/56530
* g++.dg/warn/Wsign-conversion-2.C: New.
Index: g++.dg/warn/Wsign-conversion-2.C
Hi!
While wrapper_sect_offset is always initialized if
(gnu_sections_found & SOMO_WRAPPING) != 0 and used only guarded with that
same condition, as the PR says apparently we get a false positive maybe
uninitialized warning for it still. I'd say it is a good programming style
to just initialize su
On Tue, Mar 5, 2013 at 7:16 AM, Jakub Jelinek wrote:
> 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
On Tue, Mar 5, 2013 at 12:47 AM, Paul Brook wrote:
>> 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 m
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 4, 2013 at 8:13 PM, Steven Bosscher wrote:
> 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
On Mon, 4 Mar 2013, Jan Hubicka wrote:
> > 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
On Fri, Mar 01, 2013 at 11:10:40AM +0100, Richard Biener wrote:
> Don't use NULL_TREE built_int_cst - doing so hints at that you want to
> use double_ints. Generally doing computation with trees is expensive.
> You want to avoid that at all cost. Use double-ints (yeah, you have to
> use the clunk
On Mon, 4 Mar 2013, Jakub Jelinek wrote:
> 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?
Ok.
Thanks,
Richard.
> 2013-03-04 Jakub Jelinek
>
> PR middle-
On Mon, 4 Mar 2013, Jakub Jelinek wrote:
> 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.
>
On Mon, 4 Mar 2013, Jakub Jelinek wrote:
> 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_l
> > Uses a lookup table for divisors in the range -128 .. +128, and
>
> The code that you have enabled in lib1funcs.S will utilize dynamic shift
> instructions, which are not available on SH1 or SH2. Maybe your target
> HW is SH2A which has dynamic shift instructions and you haven't noticed
>
68 matches
Mail list logo
