On Wed, Mar 06, 2013 at 01:14:45PM +0530, Shakthi Kannan wrote:
> 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 __cp
On Wednesday 06 March 2013 10:49:23 Diego Novillo wrote:
> On Tue, Mar 5, 2013 at 12:31 AM, Ian Lance Taylor wrote:
> > 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 w
2013/3/5 Eric Botcazou :
>> 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 mod
Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00678.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
My bad for missing the patch. As stated in previous message, the patch has
already been applied to ARM-Embedded-4_7-Branch.
Thanks.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Bin Cheng
> Sent: Friday, March 01, 2013 1:1
On Wed, Mar 06, 2013 at 03:00:49PM -0700, Jeff Law wrote:
> Doesn't the code in update_accumulator_with_ops need the same
> change?
No, the difference is that it uses false as the next to last argument,
i.e. inserts after gsi, in which case GSI_CONTINUE_LINKING is desirable,
so that the stmt is in
Hello,
This patch fixes a bunch of smaller issues with GATHER_STATISTICS for
bitmaps: overflows in counters and ugly output format.
Bootstrapped (with and without GATHER_STATISTICS) and regtested on
powerpc64-unknown-linux-gnu and on x86_64-unknown-linux-gnu. OK for
trunk?
Ciao!
Steven
On Wed, Mar 6, 2013 at 9:07 AM, Jakub Jelinek wrote:
> Hi!
>
> https://bugzilla.redhat.com/show_bug.cgi?id=910926
> reports that plugins aren't usable on arm, because arm-cores.def isn't
> installed into the plugins directory. arm-cores.def can't be included in
> tm_file list, because we don't wa
On Wed, 2013-03-06 at 01:43 +0100, Oleg Endo wrote:
> 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.
>
I
On 03/06/2013 09:43 AM, Jakub Jelinek wrote:
Hi!
This patch fixes a bug where force_gimple_operand_gsi was called with
bogus last argument. The before argument is true, and the stmt that is
added at the end of course should be put in between the (optional) sequence
added by force_gimple_operand
On Wed, Mar 6, 2013 at 1:54 PM, Dominique Dhumieres wrote:
> David,
>
> 'dg-do run' and 'dg-do compile' cannot be mixed in the same test
> (if needed I can look for the thread) so the tests
> vect-82_64.c and vect-83_64.c are not doing what was expected.
I did not write the original dg-do and dg-
OK, thanks.
During the discussion of UNION, I decided to have a look at the current
documentation. UNION is not mentioned (except for some commented lines),
but record structures are. Attached is an attempted to improve the
documentation.
The current version is at
http://gcc.gnu.org/onlinedocs/gfortran/S
Just to stop the compiler properly instead of erroring out on some ill-formed
inputs going through the FE down to here. No functional changes.
Tested on x86_64-suse-linux, applied on the mainline.
2013-03-06 Eric Botcazou
* gcc-interface/trans.c (Attribute_to_gnu): Abort instead of
> On Wed, Mar 6, 2013 at 5:02 PM, Jan Hubicka wrote:
> >>
> >> An interesting question is, how can you identify bitmaps that could
> >> benefit from viewing it as a tree (at least for some time). I have no
> >> ideas here. Something with detailed memory stats, of course, but then
> >> how to derive
On Wed, Mar 6, 2013 at 5:02 PM, Jan Hubicka wrote:
>>
>> An interesting question is, how can you identify bitmaps that could
>> benefit from viewing it as a tree (at least for some time). I have no
>> ideas here. Something with detailed memory stats, of course, but then
>> how to derive some measur
Hello,
this patch fixes some regressions in testsuite for x64-targets.
ChangeLog
2013-03-06 Kai Tietz
* gcc.dg/lto/20090914-2_0.c: Skip for mingw and cygwin
targets.
* gcc.dg/lto/20091013-1_1.c: Set x64-mingw as xfail.
* gcc.dg/lto/20091013-1_2.c: Likewise.
The merge includes the following 108 CLs from 190426 (excluded) up to
195968 (included) -
195968 195906 195905 195810 195782 195740 195672 195468 195460 195435
195427 195373 195356 195306 195282 195246 195214 195030 194932 194931
194926 194925 194921 194874 194831 194739 194737 194735 194725 19471
David,
'dg-do run' and 'dg-do compile' cannot be mixed in the same test
(if needed I can look for the thread) so the tests
vect-82_64.c and vect-83_64.c are not doing what was expected.
Dominique
This is another regression present on the mainline. The compiler aborts on an
aggregate whose type is a record type with a misaligned scalar component and
with a representation clause for this component that gives it a size smaller
than the default. We're incorrectly laying out the type.
Teste
On Wed, Mar 6, 2013 at 5:06 PM, Jan Hubicka wrote:
> And for the RFC, i also find it interesting experiment. I implemented some
> time ago splay tree based bitmap with API same as bitmap's but never attempted
> to put it to mainline since Danny introduced his ebitmap and there was a lot
> of
> di
On 03/06/2013 10:00 AM, Kai Tietz wrote:
> Hello,
>
> this patch fixes some regressions in testsuite for x64-targets.
>
> ChangeLog
>
> 2013-03-06 Kai Tietz
>
> * gcc.dg/lto/20090914-2_0.c: Skip for mingw and cygwin
> targets.
> * gcc.dg/lto/20091013-1_1.c: Set x64-mingw as
Hi,
On 03/06/2013 06:32 PM, Jason Merrill wrote:
On 03/06/2013 11:42 AM, Paolo Carlini wrote:
+/* NULL_TREE or error_mark_node (if decl is error_mark_node). */
+type = TREE_TYPE (decl);
I'd prefer to avoid taking the TREE_TYPE of some random thing. If
what we want is NULL_TREE or e
This is a regression present on the mainline. The compiler aborts on a loop
running over an array whose index type is a misaligned scalar type at -O3.
We're just forgetting to lift the padding type around the scalar type.
Tested on x86_64-suse-linux, applied on the mainline.
2013-06-03 Eric
Just to stop the compiler properly instead of segfaulting on some ill-formed
inputs going through the FE down to here. No functional changes.
2013-03-06 Eric Botcazou
* gcc-interface/trans.c (emit_range_check): Assert that the range type
is a numerical type and remove useles
On 03/06/2013 11:42 AM, Paolo Carlini wrote:
+ /* NULL_TREE or error_mark_node (if decl is error_mark_node). */
+ type = TREE_TYPE (decl);
I'd prefer to avoid taking the TREE_TYPE of some random thing. If what
we want is NULL_TREE or error_mark_node, let's write that rather than
On 03/06/2013 07:47 AM, Jakub Jelinek wrote:
> Hi!
>
> The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193539
> change broke the following testcase on i386. The problem is
> that it can return the result in wider mode than callers expect,
> causing either ICEs or other issues later on.
>
>
Hi!
This patch fixes a bug where force_gimple_operand_gsi was called with
bogus last argument. The before argument is true, and the stmt that is
added at the end of course should be put in between the (optional) sequence
added by force_gimple_operand_gsi and gsi_stmt (gsi), so it should use
GSI_S
... in fact, we could safely add this tiny clean-up too.
Paolo.
///
Index: cp/decl.c
===
--- cp/decl.c (revision 196497)
+++ cp/decl.c (working copy)
@@ -11712,9 +11712,6 @@ check_elaborated_type_specifier (enum
I have committed the link update to the 4.8.0 status report.
Tobias
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.871
diff -u -r1.871 index.html
--- index.html 17 Feb 2013 12:47:43 - 1
On 03/06/2013 03:34 PM, Jason Merrill wrote:
It sounds like the underlying problem is that "decl" isn't a
TYPE_DECL. So let's check for that instead.
I see. Thus, also considering that the only other use of
check_elaborated_type_specifier happens when the decl is known to be a
TYPE_DECL, I tho
Whoops, I thought I had run that test to make sure the syntax was right,
but apparently I ran a different thunk1.C instead. Fixed now.
Jason
> "Jakub" == Jakub Jelinek writes:
Jakub> 2013-02-28 Jakub Jelinek
Jakub> PR middle-end/56461
Jakub> * internal.h (struct cpp_buffer): Add to_free field.
Jakub> (_cpp_pop_file_buffer): Add third argument.
Jakub> * files.c (_cpp_stack_file): Set buffer->to_free.
Jakub> (_cpp_pop_file_b
> >
> > An interesting question is, how can you identify bitmaps that could
> > benefit from viewing it as a tree (at least for some time). I have no
> > ideas here. Something with detailed memory stats, of course, but then
> > how to derive some measure for a trade-off between list or tree view.
>
> An interesting question is, how can you identify bitmaps that could
> benefit from viewing it as a tree (at least for some time). I have no
> ideas here. Something with detailed memory stats, of course, but then
> how to derive some measure for a trade-off between list or tree view.
> Thoughts
On Tue, Mar 5, 2013 at 12:31 AM, Ian Lance Taylor wrote:
>
> 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 Taylo
Hi!
The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193539
change broke the following testcase on i386. The problem is
that it can return the result in wider mode than callers expect,
causing either ICEs or other issues later on.
It is fine to perform the cmove in promoted mode, but we shou
domi...@lps.ens.fr (Dominique Dhumieres) writes:
> The test fails with
>
> ERROR: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98: dg-skip-if 2: need 2, 3,
> or 4 arguments for " dg-skip-if 7 { target *-*-darwin* } "
>
> From the test suite the syntax should be of the kind
>
> /* { dg-skip-if "no alignm
Jason,
The test fails with
ERROR: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98: dg-skip-if 2: need 2, 3, or 4
arguments for " dg-skip-if 7 { target *-*-darwin* } "
>From the test suite the syntax should be of the kind
/* { dg-skip-if "no alignment constraints" { "avr-*-*" } { "*" } { "" } } */
T
On 03/06/2013 06:33 AM, Rainer Orth wrote:
Why not skip the whole test with dg-skip-if, since the scan is the whole
point of the testcase AFAICT? Also, please add a comment explaining why
the test is skipped, perhaps referencing the PR.
Here's what I'm checking in:
commit cd378936f38da43429
Hi!
If the second argument to TEMPLATE_ID_EXPR is NULL, there are no
explicit arguments, but we can't call copy_node (NULL).
Fixed thusly, acked by Jason in the PR, bootstrapped/regtested on
x86_64-linux and i686-linux, committed to trunk.
2013-03-06 Jakub Jelinek
PR c++/56543
>
> 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?
Seems resomable thing to do. However I guess a lot of users are still
have non-linker-plugin
Julian Brown wrote:
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 inde
It sounds like the underlying problem is that "decl" isn't a TYPE_DECL.
So let's check for that instead.
Jason
On Wed, Mar 6, 2013 at 11:31 AM, Rainer Orth
wrote:
> This patch fixes the failures by backporting the use of thr_stksegment
> from gc 7.2c.
>
> Bootstrapped without regressions on i386-pc-solaris2.{9,10,11} and
> sparc-sun-solaris2.{9,10,11}, fixes the i386-pc-solaris2.11 failures.
>
> Ok for ma
On 03/06/2013 02:25 PM, Rainer Orth wrote:
Unless those symbols were explicitly exported in config/abi/pre/gnu*.ver
(which they are not, otherwise the x86_64-unknown-linux-bootstrap would
have shown a failure), they couldn't make it into libstdc++.so. They
only occur on Solaris because gld expli
Hi Paolo,
Rainer Orth writes:
> diff --git a/libstdc++-v3/scripts/extract_symvers.in
> b/libstdc++-v3/scripts/extract_symvers.in
> --- a/libstdc++-v3/scripts/extract_symvers.in
> +++ b/libstdc++-v3/scripts/extract_symvers.in
> @@ -49,9 +49,12 @@ SunOS)
> if
Hi,
On 03/06/2013 12:08 PM, Rainer Orth wrote:
Rainer Orth writes:
Andreas Schwab writes:
Rainer Orth writes:
diff --git a/libstdc++-v3/scripts/extract_symvers.in
b/libstdc++-v3/scripts/extract_symvers.in
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_
Hi!
On Wed, Mar 06, 2013 at 06:57:03PM +0800, Matthias Klose wrote:
> There is still vxworks-dummy.h, which is not installed, see PR45078. Would the
> same approach work?
Like this? Untested though, and no access to most of the targets.
2013-03-06 Jakub Jelinek
PR plugins/45078
Jack Howarth writes:
> 2013-03-05 Jack Howarth
>
> PR debug/53363
> * g++.dg/debug/dwarf2/thunk1.C: Skip final scan on darwin.
>
> Index: gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
> ===
> --- gcc/testsuite/g++.dg/debu
Since Solaris 11.1/x86, a few 32-bit boehm-gc testcases started to FAIL:
FAIL: boehm-gc.c/gctest.c -O2 execution test
FAIL: boehm-gc.c/leak_test.c -O2 execution test
FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
FAIL: boehm-gc.lib/staticrootstest.c -O2 execution test
They all SEGV on the
Rainer Orth writes:
> Andreas Schwab writes:
>
>> Rainer Orth writes:
>>
>>> diff --git a/libstdc++-v3/scripts/extract_symvers.in
>>> b/libstdc++-v3/scripts/extract_symvers.in
>>> --- a/libstdc++-v3/scripts/extract_symvers.in
>>> +++ b/libstdc++-v3/scripts/extract_symvers.in
>>> @@ -49,9 +49,1
On Wed, Mar 06, 2013 at 06:57:03PM +0800, Matthias Klose wrote:
> Am 06.03.2013 17:07, schrieb Jakub Jelinek:
> > https://bugzilla.redhat.com/show_bug.cgi?id=910926
> > reports that plugins aren't usable on arm, because arm-cores.def isn't
> > installed into the plugins directory. arm-cores.def ca
Am 06.03.2013 17:07, schrieb Jakub Jelinek:
> Hi!
>
> https://bugzilla.redhat.com/show_bug.cgi?id=910926
> reports that plugins aren't usable on arm, because arm-cores.def isn't
> installed into the plugins directory. arm-cores.def can't be included in
> tm_file list, because we don't want to inc
On Tue, Mar 5, 2013 at 5:16 PM, Steven Bosscher wrote:
> On Tue, Mar 5, 2013 at 3:48 PM, Michael Matz wrote:
>> Iteration isn't easy on trees without a pointer to the parent (i.e.
>> enlarging each node), you need to remember variably sized context in the
>> iterator (e.g. the current stack of nod
The testcase in PR56294 shows that we may not depend on the
order symbols are registered for renaming for inserting new
PHI nodes for them. Instead we should always insert them
in order of their symbol UID. This is a regression from the
referenced_vars removal series as that introduced the
vec o
On 06/03/13 09:07, Jakub Jelinek wrote:
Hi!
https://bugzilla.redhat.com/show_bug.cgi?id=910926
reports that plugins aren't usable on arm, because arm-cores.def isn't
installed into the plugins directory. arm-cores.def can't be included in
tm_file list, because we don't want to include it direct
Hi!
https://bugzilla.redhat.com/show_bug.cgi?id=910926
reports that plugins aren't usable on arm, because arm-cores.def isn't
installed into the plugins directory. arm-cores.def can't be included in
tm_file list, because we don't want to include it directly, nor in
HeaderInclude in arm.opt (that
On Tue, 5 Mar 2013, 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 lar
59 matches
Mail list logo
