Mike Stump mikest...@comcast.net wrote:
On Aug 10, 2013, at 3:03 AM, Richard Biener
richard.guent...@gmail.com wrote:
Mike Stump mikest...@comcast.net wrote:
On Aug 9, 2013, at 3:36 PM, Diego Novillo dnovi...@google.com
wrote:
This patch is still WIP. It builds stage1, but I'm getting ICEs
Hi,
I have to use a vector, because I need to iterate it while
manipulating it as a stack.
Ok. Strictly speaking, you could't do that with a stack. Maybe you should say
something like we add and remove elements FILO. But don't bother for now.
Paolo
I see, yes LTO can deal with this better since it has global
information. In non-LTO mode (including LIPO) we have the issue.
Either Martin or me will implement merging of the multiple copies at
LTO link time. This is needed for Martin's code unification patch anyway.
Theoretically gcov
Hi,
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html
Message-ID: 20130514191244.ga12...@host2.jankratochvil.net
Thanks,
Jan
Cc'ing Rong since he is also working on trying to address the comdat
profile issue. Rong, you may need to see an earlier message for more
context:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00558.html
Teresa
On Sun, Aug 11, 2013 at 5:21 AM, Jan Hubicka hubi...@ucw.cz wrote:
I see, yes LTO
Given that I did not receive any feedback on my earlier email on this topic, I
would like to send this patch for RFC. I'm not expert at this configury-stuff,
so please try to comment on both the test proposed and my actual implementation
:)
The idea is to find a patch which both catches
Hello,
I did a collection of systemtap graphs for GIMP.
All these graphs were created with enabled LTO, profiling and -O2.
1) gimp-reordered.pdf - function are reordered according to my newly
created profile that utilizes LTO infrastructure
2) gimp-no-top-level-reorder.pdf - (GCC rev.
Hi Jason,
I decided to go ahead and submit the latest cleaned up version of the generic
lambda and implicit function template patches. I think all review comments have
been addressed. As well as the cleanup there are a few enhancements; generic
lambda instantiations in diagnostics now show
* cp-tree.h (struct saved_scope): Add x_fully_implicit_template bit ...
(fully_implicit_template): ... and provide conventional access to it.
(type_uses_auto_or_concept): Declare.
(is_auto_or_concept): Declare.
(add_implicit_template_parms): Declare.
* parser.c (cp_parser_lambda_declarator_opt): Accept template parameter
list with std=gnu++1y.
(cp_parser_lambda_body): Don't call 'expand_or_defer_fn' for lambda call
operator template to avoid adding template result to symbol table.
* lambda.c
* error.c (dump_function_decl): Use standard diagnostic flow to dump a
lambda diagnostic, albeit without stating the function name or
duplicating the parameter spec (which is dumped as part of the type).
---
gcc/cp/error.c | 22 +++---
1 file changed, 11
* pt.c: Grammar fix in comments (it's to its).
---
gcc/cp/pt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ce899ef..78b7a97 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1986,7 +1986,7 @@ determine_specialization (tree
On 08/11/2013 01:08 AM, Caroline Tice wrote:
OK, I have removed the attempt to use $HOME for the logs; they will
now either go into the directory specified by the environment variable
VTV_LOGS_DIR, or they will go into the current directory. I also
added code to use secure_getenv, rather than
Hi,
thinking about it a bit more, I suppose easiest way is to
1) make separate sets of counters for each comdat and place them
into comdat section named as DECL_COMDAT_GROUP (node) + cfg_checksum +
individual_counter_counts.
This will make linker to unify the sections for us.
2) extend API
Hi Janus,
So: Ok for trunk from my side.
However, I would prefer to disable the warning by default, but include
it in -Wall.
Here's a patch to do just that.
Regression-tested (hence the changes to the existing test cases :-)
OK for trunk? Once it goes in, I will also update the WWW
Hi,
committed to mainline.
Thanks,
Paolo.
2013-08-11 Paolo Carlini paolo.carl...@oracle.com
PR c++/53349
* g++.dg/cpp0x/constexpr-ice8.C: New.
Index: g++.dg/cpp0x/constexpr-ice8.C
===
2013/8/11 Thomas Koenig tkoe...@netcologne.de:
Hi Janus,
So: Ok for trunk from my side.
However, I would prefer to disable the warning by default, but include
it in -Wall.
Here's a patch to do just that.
Regression-tested (hence the changes to the existing test cases :-)
OK for trunk?
Hi,
this patch adds simple cost model into indirect call speculation. First we do
not
turn calls into speculative calls when it seems bad idea (i.e. call is cold)
and during inlining we remove speculations that do not seem benefical.
On modern chip speculative call sequence without inlining is
Committed.
Gerald
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.887
diff -u -3 -p -r1.887 index.html
--- index.html 31 May 2013 11:41:08 - 1.887
+++ index.html 12 Aug 2013
David suggested adding this link, and I think it fits nicely.
Applied.
Gerald
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.119
diff -r1.119 style.mhtml
160a161,164
a
This patch fixes PR rtl-optimizations/57451 by preventing scopes and
therefore lexical blocks from crossing split section boundaries.
This will prevent debug info generation from using DW_AT_low_pc/high_pc
pairs across the section boundary.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
I like the approach in general -- in the past, indirect call promotion
and function inlining heuristics are disconnected -- which can lead to
either missing promotions or useless ones. This approach solves the
problem.
On Sun, Aug 11, 2013 at 4:11 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this
22 matches
Mail list logo
