Hi!
On Tue, 3 Jun 2014 11:55:44 +0200, I wrote:
Ping -- OK to commit to trunk?
Even though several of those who I'd consider regular GCC developers do
agree with this patch (see also https://gcc.gnu.org/PR61334), that is
not enough consensus to consider this patch approved, right? Wouldn't
it
On Mon, Jun 9, 2014 at 11:47 PM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
On Tue, 3 Jun 2014 11:55:44 +0200, I wrote:
Ping -- OK to commit to trunk?
Even though several of those who I'd consider regular GCC developers do
agree with this patch (see also
On Tue, Jun 10, 2014 at 8:47 AM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
On Tue, 3 Jun 2014 11:55:44 +0200, I wrote:
Ping -- OK to commit to trunk?
Even though several of those who I'd consider regular GCC developers do
agree with this patch (see also
Hi!
Ping -- OK to commit to trunk?
On Wed, 28 May 2014 23:55:31 +0200, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski pins...@gmail.com wrote:
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
r210901 breaks bootstrap
Hi!
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski pins...@gmail.com wrote:
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen'
Hi!
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski pins...@gmail.com wrote:
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
r210901 breaks bootstrap on targets not supporting strnlen, e.g.,
darwin10.
../../_clean/gcc/lto-cgraph.c:976:68:
This patch broke Solaris bootstrap:
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'void
solaris_elf_asm_comdat_section(const char*, unsigned int, tree)':
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:213:17: error:
'decl_comdat_group' was not declared in this scope
Jan Hubicka hubi...@ucw.cz writes:
This patch broke Solaris bootstrap:
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'void
solaris_elf_asm_comdat_section(const char*, unsigned int, tree)':
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:213:17: error:
'decl_comdat_group' was
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this
scope
libgfortran/configure defines HAVE_STRNLEN on targets supporting it.
The same revision also breaks the test g++.dg/tls/diag-1.C
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr wrote:
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in
this scope
strnlen should be declared in include/libiberty.h
On my side, I can see that r210901 breaks AArch64 compiler build:
gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree_node*)’:
gcc/config/aarch64/aarch64.c:8136: error: ‘decl_comdat_group’ was not
declared in this scope
Christophe.
On
Jan Hubicka hubi...@ucw.cz writes:
I'm fine with enlarging tree_function_decl for now - ideally we'd push
stuff from it elsewhere (like target and optimization option tree nodes,
or most of the visibility and symbol related stuff). Not sure why
tree_type_decl inherits from
On my side, I can see that r210901 breaks AArch64 compiler build:
gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree_node*)’:
gcc/config/aarch64/aarch64.c:8136: error: ‘decl_comdat_group’ was not
declared in this scope
This sould be
On Thu, May 22, 2014 at 2:49 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
On Wed, May 21, 2014 at 3:16 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
this demonstrates how results of ipa-prop escape analysis from
I'm fine with enlarging tree_function_decl for now - ideally we'd push
stuff from it elsewhere (like target and optimization option tree nodes,
or most of the visibility and symbol related stuff). Not sure why
tree_type_decl inherits from tree_decl_non_common (and thus
tree_decl_with_vis).
On Thu, May 22, 2014 at 8:11 PM, Jan Hubicka hubi...@ucw.cz wrote:
It won't be so easy, because struct function is really built at
relatively convoluted
places within frontend before cgraph node is assigned to them (I tried
that few years
back).
Well, just call cgraph create node from
Well, allocate_struct_function has a abstract_p argument for that. But
yes, a simple patch like
Index: gcc/function.c
===
--- gcc/function.c (revision 210845)
+++ gcc/function.c (working copy)
@@ -64,6 +64,7 @@
Hi,
On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
On Wed, May 21, 2014 at 3:16 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
this demonstrates how results of ipa-prop escape analysis from
previous patches can be used at a later stage of compilation by
directly
On Thu, May 22, 2014 at 2:49 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
On Wed, May 21, 2014 at 3:16 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
this demonstrates how results of ipa-prop escape analysis from
previous
Can we? If the body is not readily available we only have decl and
cgraph-node, not struct function.
I suppose we could exchange the struct function pointer in
tree_function_decl for a cgraph_node pointer and put
the struct function pointer into the cgraph_node.
Of course that may
On May 22, 2014 5:24:33 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
Can we? If the body is not readily available we only have decl and
cgraph-node, not struct function.
I suppose we could exchange the struct function pointer in
tree_function_decl for a cgraph_node pointer and put
the
It won't be so easy, because struct function is really built at
relatively convoluted
places within frontend before cgraph node is assigned to them (I tried
that few years
back).
Well, just call cgraph create node from struct Funktion allocation.
That will make uninstantiated templates to
Hi,
this demonstrates how results of ipa-prop escape analysis from
previous patches can be used at a later stage of compilation by
directly returning them from gimple_call_arg_flags which currently
relies on fnspec annotations.
Bootstrapped and tested on x86_64-linux and also passes LTO
On Wed, May 21, 2014 at 3:16 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
this demonstrates how results of ipa-prop escape analysis from
previous patches can be used at a later stage of compilation by
directly returning them from gimple_call_arg_flags which currently
relies on fnspec
24 matches
Mail list logo
