Re: [C PATCH] Handle typedef name as a flexible array member (PR c/64768)
On Fri, Feb 13, 2015 at 08:53:38PM +, Joseph Myers wrote:
On Fri, 13 Feb 2015, Marek Polacek wrote:
Since we had no testing for such cases whatsoever, I took existing flexible
array member tests and duplicated them, only adjusted them to use a typedef
name, so that we test as many scenarios as possible - I think this ought to
give us a reasonable level of confidence that this works as expected now.
Bootstrapped/regtested on {ppc64,x86_64}-linux, ok for trunk?
OK, though the use of
/* { dg-bogus warning warning in place of error } */
is a relic of when dg-error / dg-warning used not to verify that
diagnostics were in fact errors / warnings; now they do check that, simply
using dg-error (on the line with the diagnostic, so not needing { target
*-*-* } and a line number) suffices rather than needing such a dg-bogus /
dg-error pair.
Thanks, I've fixed that up and committed the patch.
Marek
Re: [committed] Change Q and T constraints to memory constraints
On 2015-02-13, at 12:08 PM, Richard Henderson wrote: On 02/13/2015 05:22 AM, John David Anglin wrote: + /* Reload sometimes tries to put const data symbolic operands in + readonly memory. The HP SOM linker doesn't allow symbolic data + in readonly memory. */ + if (TARGET_SOM + !function_label_operand (x, VOIDmode) + symbolic_operand (x, VOIDmode)) +return true; You probably want to remove the SOM test. Even if ELF can represent this, it will lead to DT_TEXTREL and relocations against the read-only memory. Unfortunately, this creates new problems. When there is a constant offset that won't fit in 14 bits, we ICE. I think this could be improved to 21 bits but it's tough to load an operand with a larger offset with just one register, particularly when generating PIC code. I need to research what happens on SOM with large offsets. Possibly the constant can somehow be forced into the data section where the relocations aren't a problem? Dave -- John David Anglin dave.ang...@bell.net
Re: [PATCH][RFA][LRA] Don't try to break down subreg expressions if insn already matches
On Feb 13, 2015, at 1:47 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: On 13/02/15 10:10, pins...@gmail.com wrote: On Feb 13, 2015, at 1:48 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: Hi all, In my tree added a pattern to the arm backend that's supposed to match: (set (reg:SI r0) (subreg:SI (plus:DI (mult:DI (sign_extend:DI (reg:SI r1)) (sign_extend:DI (reg:SI r2))) (const_int 2147483648 [0x8000])) 4)) That is, take two SImode regs, sign-extend to DImode, multiply in DImode, add a const_int and take the most significant SImode subreg. Seems better to use shifts for the most significant simode and low part subreg after that. Isn't that what other targets do? I thought about that, but combine tries to match: (set (reg/i:SI 0 r0) (subreg:SI (plus:DI (mult:DI (sign_extend:DI (reg:SI 0 r0 [ a ])) (sign_extend:DI (reg:SI 1 r1 [ b ]))) (const_int 2147483648 [0x8000])) 4)) Looking at the RTL dumps all shifts are gone by the time combine is reached (in this case cse1 removes the shifts) FYI, (and not related to the core issue of this patch) The use of mult vs shift by combine is a problem that Venkat is working on, see [RFC] Tighten memory type assumption in RTL combiner pass . The combiner uses MULTs instead of SHIFTs for rtx'es that look like addresses, even when they are, in fact, mere logic/arithmetic operations. -- Maxim Kuvyrkov www.linaro.org
Re: [PATCH 09/36] floatformat.h: Wrap in extern C.
On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves pal...@redhat.com wrote: On 02/09/2015 11:35 PM, Andrew Pinski wrote: On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves pal...@redhat.com wrote: Just like libiberty.h. So that C++ programs, such as GDB when built as a C++ program, can use it. Why is not needed for GCC building with C++ compiler? Because it doesn't include it. The header of the file claims it is part of GDB, though MAINTAINERS nowadays says that everything under include/ is owned by GCC. Wait, what? The actual wording is: The rule is that if the file exists in the gcc tree then gcc owns it. It originated from this thread, https://sourceware.org/ml/gdb/2013-11/msg00025.html That's not the first message in the thread, but that's where I remember wanting to see something written down. Perhaps kinda unfortunate for things like include/gdb/gdb-index.h. But at least it's a rule that can be expressed in one sentence, and I don't think it's been a problem.
Re: Chromium: LTO
Hi, Maritn has notced that we spend a lot of time in simple cgraph/varpool predicates. The patch bellow reorganizes inlines so the fast paths get fast. perf report: 18.79% lto1-wpa lto1 [.] do_estimate_growth_1(cgraph_node*, void*) 12.48% lto1-wpa lto1 [.] cgraph_node::can_remove_if_no_direct_calls_and_refs_p() 5.86% lto1-wpa lto1 [.] symtab_node::used_from_object_file_p_worker(symtab_node*) 5.69% lto1-wpa lto1 [.] cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*, void*), void*, bool) 5.01% lto1-wpa-stream lto1 [.] streamer_tree_cache_lookup(streamer_tree_cache_d*, tree_node*, unsigned int*) 4.84% lto1-wpa lto1 [.] cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*, void*), void*, bool, bool) 2.44% lto1-wpa lto1 [.] inflate_fast 2.10% lto1-wpa-stream lto1 [.] DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) 2.03% lto1-wpa-stream lto1 [.] linemap_lookup(line_maps*, unsigned int) 1.30% lto1-wpa-stream [kernel.kallsyms][k] isolate_migratepages_range 1.27% lto1-wpa lto1 [.] symtab_node::iterate_direct_aliases(unsigned int, ipa_ref*) 1.21% lto1-wpa-stream lto1 [.] DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) 1.19% lto1-wpa-stream lto1 [.] streamer_write_uhwi_stream(lto_output_stream*, unsigned long) 0.85% lto1-wpa lto1 [.] compare_tree_sccs_1(tree_node*, tree_node*, tree_node***) 0.83% lto1-wpa lto1 [.] streamer_read_uhwi(lto_input_block*) 0.74% lto1-wpa-stream lto1 [.] streamer_tree_cache_insert_1(streamer_tree_cache_d*, tree_node*, unsigned int, unsigned int*, bool) 0.72% lto1-wpa lto1 [.] ht_lookup_with_hash(ht*, unsigned char const*, unsigned long, unsigned int, ht_lookup_option) 0.70% lto1-wpa-stream [kernel.kallsyms][k] compaction_alloc 0.68% lto1-wpa lto1 [.] unify_scc(streamer_tree_cache_d*, unsigned int, unsigned int, unsigned int, unsigned int) 0.66% lto1-wpa-stream lto1 [.] lto_output_tree(output_block*, tree_node*, bool, bool) 0.66% lto1-wpa-stream libc-2.19.so [.] _int_malloc 0.66% lto1-wpa-stream lto1 [.] hash_tablehash_maptree_node*, unsigned int, default_hashmap_traits::hash_entry, xcallocator, true::expand() 0.62% lto1-wpa-stream lto1 [.] streamer_write_tree_bitfields(output_block*, tree_node*) 0.61% lto1-wpa lto1 [.] streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) 0.53% lto1-wpa lto1 [.] lto_cgraph_replace_node(cgraph_node*, cgraph_node*) 0.49% lto1-wpa [kernel.kallsyms][k] copy_pte_range Bootstrapped/regtested x86_64-linux, comitted. Honza * ipa-chkp.c: Use iterate_direct_aliases. * symtab.c (resolution_used_from_other_file_p): Move inline. (symtab_node::create_reference): Fix formating. (symtab_node::has_aliases_p): Move inline; use iterate_direct_aliases. (symtab_node::iterate_reference): Move inline. (symtab_node::iterate_referring): Move inline. (symtab_node::iterate_direct_aliases): Move inline. (symtab_node::used_from_object_file_p_worker): Inline into ... (symtab_node::used_from_object_file_p): ... this one; move inline. (symtab_node::call_for_symbol_and_aliases): Move inline; use iterate_direct_aliases. (symtab_node::call_for_symbol_and_aliases_1): New method. (cgraph_node::call_for_symbol_and_aliases): Move inline; use iterate_direct_aliases. (cgraph_node::call_for_symbol_and_aliases_1): New method. (varpool_node::call_for_node_and_aliases): Rename to ... (varpool_node::call_for_symbol_and_aliases): ... this one; Move inline; use iterate_direct_aliases. (varpool_node::call_for_symbol_and_aliases_1): New method. * ipa.c (ipa_single_use): Use iterate_direct_aliases. (ipa_discover_readonly_nonaddressable_var): Update. * ipa-devirt.c: Fix formating. * cgraph.c (cgraph_node::can_remove_if_no_direct_calls_and_refs_p): Move inline. (cgraph_node::call_for_symbol_and_aliases): Move inline. (cgraph_node::call_for_symbol_and_aliases_1): New function.. * cgraph.h (used_from_object_file_p_worker): Remove. (resolution_used_from_other_file_p): Move inline. (symtab_node::has_aliases_p): Move inline; use iterate_direct_aliases.
Re: [PATCH 09/36] floatformat.h: Wrap in extern C.
On 02/14/2015 05:29 PM, Doug Evans wrote: On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves pal...@redhat.com wrote: On 02/09/2015 11:35 PM, Andrew Pinski wrote: Why is not needed for GCC building with C++ compiler? Because it doesn't include it. The header of the file claims it is part of GDB, though MAINTAINERS nowadays says that everything under include/ is owned by GCC. Wait, what? The actual wording is: The rule is that if the file exists in the gcc tree then gcc owns it. I was paraphrasing, and simplified it. That distinction seems irrelevant to me here because the file does exist in the gcc tree. It's necessary to build libiberty (for libiberty/floatformat.o). It's a fact that the header claims it is part of GDB: ~~ /* IEEE floating point support declarations, for GDB, the GNU Debugger. Copyright (C) 1991-2015 Free Software Foundation, Inc. This file is part of GDB. (...) ~~ I guess it should say that it is part of libiberty instead. It originated from this thread, https://sourceware.org/ml/gdb/2013-11/msg00025.html That's not the first message in the thread, but that's where I remember wanting to see something written down. Perhaps kinda unfortunate for things like include/gdb/gdb-index.h. But at least it's a rule that can be expressed in one sentence, and I don't think it's been a problem. I'm confused -- I didn't say it was a problem, nor expressed any concern with the rule. I just was pointing out facts. ISTM that the procedure here is to push this change first through the gcc repo first, and then merge it to binutils-gdb git. Is that wrong? Thanks, Pedro Alves
Re: patch to fix rtl documentation for new floating point comparisons
On 10/02/2015 22:46, Joseph Myers wrote: It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the choice of definition is a matter of what's convenient for the implementation (and which choice you make determines which existing code in GCC should be considered incorrect). It would be different from e.g. !UNLT and GE differing only in that UNLT is quiet and GE is signaling. So it makes sense to me to keep LTGT as signaling. Paolo
Re: [PATCH PR target/65058] AIX: missing extern decorations [DS] for functions and [RW] for variables
Hi, Michael Thanks for noticing this. This patch generally seems to be on the right track. The original ASM_OUTPUT_EXTERNAL code was not completely correct in the pedantic sense. It should use [UA] mapping class instead of [RW] for all non-function descriptor symbols. This patch also needs a dg-final scan-assembler test to check for [DS] and [UA] to ensure that this does not regress again in the future. Thanks, David On Fri, Feb 13, 2015 at 5:02 PM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Hi David, this is the patch I'm currently testing with gcc-4.8.4 for http://gcc.gnu.org/PR65058 Thanks! /haubi/
Re: [PATCH 09/36] floatformat.h: Wrap in extern C.
On Sat, Feb 14, 2015 at 10:36 AM, Pedro Alves pal...@redhat.com wrote: On 02/14/2015 05:29 PM, Doug Evans wrote: On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves pal...@redhat.com wrote: On 02/09/2015 11:35 PM, Andrew Pinski wrote: Why is not needed for GCC building with C++ compiler? Because it doesn't include it. The header of the file claims it is part of GDB, though MAINTAINERS nowadays says that everything under include/ is owned by GCC. Wait, what? The actual wording is: The rule is that if the file exists in the gcc tree then gcc owns it. I was paraphrasing, and simplified it. That distinction seems irrelevant to me here because the file does exist in the gcc tree. It's necessary to build libiberty (for libiberty/floatformat.o). No worries, I just wanted to make sure it didn't say something it shouldn't. It's a fact that the header claims it is part of GDB: ~~ /* IEEE floating point support declarations, for GDB, the GNU Debugger. Copyright (C) 1991-2015 Free Software Foundation, Inc. This file is part of GDB. (...) ~~ I guess it should say that it is part of libiberty instead. At the least the current wording is confusing. It originated from this thread, https://sourceware.org/ml/gdb/2013-11/msg00025.html That's not the first message in the thread, but that's where I remember wanting to see something written down. Perhaps kinda unfortunate for things like include/gdb/gdb-index.h. But at least it's a rule that can be expressed in one sentence, and I don't think it's been a problem. I'm confused -- I didn't say it was a problem, nor expressed any concern with the rule. I just was pointing out facts. I didn't say you said it was a problem. It was just an offhand comment about the rule itself, not anything you said. ISTM that the procedure here is to push this change first through the gcc repo first, and then merge it to binutils-gdb git. Is that wrong? That's the procedure as I understand it.
mli...@suse.cz
Hi,
this patch speeds up do_estimate_growth_1 and makes it more correct in presence
of uninlinable edges (such as those in thunks)
Bootstrapped/regtested x86_64-linux, comitted.
* ipa-inline-analysis.c (growth_data): Add uninlinable field.
(do_estimate_growth_1): Record if any uninlinable edge was seen.
(estimate_growth): Handle uninlinable edges correctly.
(check_callers): New.
(growth_likely_positive): Handle aliases correctly.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 220709)
+++ ipa-inline-analysis.c (working copy)
@@ -3901,6 +3901,7 @@ struct growth_data
{
struct cgraph_node *node;
bool self_recursive;
+ bool uninlinable;
int growth;
};
@@ -3917,6 +3918,12 @@ do_estimate_growth_1 (struct cgraph_node
{
gcc_checking_assert (e-inline_failed);
+ if (cgraph_inline_failed_type (e-inline_failed) == CIF_FINAL_ERROR)
+ {
+ d-uninlinable = true;
+ continue;
+ }
+
if (e-caller == d-node
|| (e-caller-global.inlined_to
e-caller-global.inlined_to == d-node))
@@ -3932,10 +3939,10 @@ do_estimate_growth_1 (struct cgraph_node
int
estimate_growth (struct cgraph_node *node)
{
- struct growth_data d = { node, 0, false };
+ struct growth_data d = { node, false, false, 0 };
struct inline_summary *info = inline_summaries-get (node);
- node-call_for_symbol_thunks_and_aliases (do_estimate_growth_1, d, true);
+ node-call_for_symbol_and_aliases (do_estimate_growth_1, d, true);
/* For self recursive functions the growth estimation really should be
infinity. We don't want to return very large values because the growth
@@ -3943,7 +3950,7 @@ estimate_growth (struct cgraph_node *nod
return zero or negative growths. */
if (d.self_recursive)
d.growth = d.growth info-size ? info-size : d.growth;
- else if (DECL_EXTERNAL (node-decl))
+ else if (DECL_EXTERNAL (node-decl) || d.uninlinable)
;
else
{
@@ -3962,6 +3969,28 @@ estimate_growth (struct cgraph_node *nod
return d.growth;
}
+/* Verify if there are fewer than MAX_CALLERS. */
+
+static bool
+check_callers (cgraph_node *node, int *max_callers)
+{
+ ipa_ref *ref;
+
+ for (cgraph_edge *e = node-callers; e; e = e-next_caller)
+{
+ (*max_callers)--;
+ if (!*max_callers
+ || cgraph_inline_failed_type (e-inline_failed) == CIF_FINAL_ERROR)
+ return true;
+}
+
+ FOR_EACH_ALIAS (node, ref)
+if (check_callers (dyn_cast cgraph_node * (ref-referring), max_callers))
+ return true;
+
+ return false;
+}
+
/* Make cheap estimation if growth of NODE is likely positive knowing
EDGE_GROWTH of one particular edge.
@@ -3969,7 +3998,8 @@ estimate_growth (struct cgraph_node *nod
and skip computation if there are too many callers. */
bool
-growth_likely_positive (struct cgraph_node *node, int edge_growth
ATTRIBUTE_UNUSED)
+growth_likely_positive (struct cgraph_node *node,
+ int edge_growth)
{
int max_callers;
struct cgraph_edge *e;
@@ -4000,9 +4030,16 @@ growth_likely_positive (struct cgraph_no
for (e = node-callers; e; e = e-next_caller)
{
max_callers--;
- if (!max_callers)
+ if (!max_callers
+ || cgraph_inline_failed_type (e-inline_failed) == CIF_FINAL_ERROR)
return true;
}
+
+ ipa_ref *ref;
+ FOR_EACH_ALIAS (node, ref)
+if (check_callers (dyn_cast cgraph_node * (ref-referring),
max_callers))
+ return true;
+
return estimate_growth (node) 0;
}
[PATCH, wwwdoc] Describe the changes of NDS32 port in GCC-5.0.
Hi, all, There are some major changes on NDS32 port in GCC-5.0: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00316.html https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00992.html https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00993.html This patch is to describe them in changes.html. Although it is target-specific part, it is welcome for others to have review comments on its format, layout, and english words improvement. If there is no other comments about this patch, I will commit it into trunk next week. :) Best regards, jasonwucj Index: htdocs/gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.77 diff -u -r1.77 changes.html --- htdocs/gcc-5/changes.html 2 Feb 2015 08:49:09 - 1.77 +++ htdocs/gcc-5/changes.html 5 Feb 2015 02:28:05 - @@ -560,6 +560,19 @@ optimize the Linux kernel./li /ul +h3 id=nds32NDS32/h3 + ul +liThe variadic function ABI implementation is now compatible to the past +Andes toolchains where caller uses registers to pass arguments and callee +is in charge of pushing them into stack./li +liThe options code-mforce-fp-as-gp/code, code-mforbid-fp-as-gp/code, +and code-mex9/code have been removed since they are not available yet in +the nds32 port of binutils package./li +liNew option code-mcmodel=small/medium/large/code is provided to +support varied code model on code generation. The code-mgp-direct/code +option now becomes meaningless and can be discarded./li + /ul + h3 id=shSH/h3 ul liThe compiler will now pass the appropriate code--isa=/code option
[PING ^ 5] [PATCH, AARCH64] Add support for -mlong-calls option
Ping ... Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html Any comments, Richard? Thanks.
[PATCH] Fix some new AIX testsuite failures
The recent PowerPC tests are not relevant to AIX.
And builtin-noret-{12}, now produce valid AIX linker warnings.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Committed.
Thanks, David
* gcc.target/powerpc/pr64205.c: Skip on AIX.
* gcc.target/powerpc/pr64505.c: Skip on AIX.
* gcc.dg/torture/builtin-noret-1.c: Ignore AIX linker warnings.
* gcc.dg/torture/builtin-noret-2.c: Ignore AIX linker warnings.
Index: gcc.target/powerpc/pr64505.c
===
--- gcc.target/powerpc/pr64505.c(revision 220709)
+++ gcc.target/powerpc/pr64505.c(working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile { target { powerpc*-*-* ilp32 } } } */
+/* { dg-skip-if { powerpc*-*-aix* } { * } { } } */
/* { dg-options -O2 -mpowerpc64 } */
/*
Index: gcc.target/powerpc/pr64205.c
===
--- gcc.target/powerpc/pr64205.c(revision 220709)
+++ gcc.target/powerpc/pr64205.c(working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile { target { powerpc*-*-* ilp32 } } } */
+/* { dg-skip-if { powerpc*-*-aix* } { * } { } } */
/* { dg-skip-if do not override -mcpu { powerpc*-*-* } { -mcpu=*
} { -mcpu=G5 } } */
/* { dg-options -O2 -mcpu=G5 -maltivec -m32 } */
Index: gcc.dg/torture/builtin-noret-2.c
===
--- gcc.dg/torture/builtin-noret-2.c(revision 220709)
+++ gcc.dg/torture/builtin-noret-2.c(working copy)
@@ -4,6 +4,8 @@
/* { dg-options -multiply_defined suppress { target powerpc-*-darwin* } } */
/* { dg-do link } */
/* { dg-require-weak } */
+/* { dg-prune-output recognized } */
+/* { dg-prune-output ld: 0711-768 WARNING } */
extern void tabort (void);
extern void texit (void);
Index: gcc.dg/torture/builtin-noret-1.c
===
--- gcc.dg/torture/builtin-noret-1.c(revision 220709)
+++ gcc.dg/torture/builtin-noret-1.c(working copy)
@@ -3,6 +3,8 @@
/* { dg-options -multiply_defined suppress { target powerpc-*-darwin* } } */
/* { dg-do link } */
/* { dg-require-weak } */
+/* { dg-prune-output recognized } */
+/* { dg-prune-output ld: 0711-768 WARNING } */
extern void abort (void);
extern void exit (int);
