Re: [Patch, Fortran, OOP] PR 52968: Call to type-bound procedure wrongly rejected
Janus Weil wrote: here is a small patch for an OOP problem. For discussion see the PR. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK and thanks for the patch. Note, however, that since Bernhard's patch*, using cleanup-modules is usually not needed. * http://gcc.gnu.org/ml/fortran/2012-03/msg00069.html Tobias 2012-04-15 Janus Weil ja...@gcc.gnu.org PR fortran/52968 * class.c (gfc_build_class_symbol): Make sure the 'f2k_derived' namespace is present. 2012-04-15 Janus Weil ja...@gcc.gnu.org PR fortran/52968 * gfortran.dg/typebound_call_23.f03: New test case.
Re: [C++ Patch] PR 49152
On Mon, Apr 16, 2012 at 12:42 AM, Marc Glisse marc.gli...@inria.fr wrote: On Sun, 15 Apr 2012, Gabriel Dos Reis wrote: a hybrid approach; I would suggest something like this: (a) if caret is in effect, then print the caret pointing to the symbol in question; otherwise (b) print the symbol and the type (as suggested by Marc). I may have forgotten the details, but looking at the beginning of the PR, don't we always want the types? Yes. Show where the failing operator== is, and print the types of the 2 arguments? I tried to parenthesize your sentence so it meant that, but it wasn't convincing... -- Marc Glisse
[Fortran] Patch ping
Dear all, first, I would like to ping my patch: - [Patch, Fortran] PR52864 - fix actual/formal checks http://gcc.gnu.org/ml/fortran/2012-04/msg00059.html Other patches with pending review: - [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules http://gcc.gnu.org/ml/fortran/2012-04/msg00033.html Caveat: ABI breakage - [patch, fortran] PR fortran/52537 Optimize string comparisons against empty strings http://gcc.gnu.org/ml/fortran/2012-04/msg00068.html - [Patch, libfortran] Combine get_mem and internal_malloc_size http://gcc.gnu.org/ml/fortran/2012-03/msg00127.html Approved but not yet committed: My patches: - (My TREE_PUBLIC() = 0 for module procedures test-case fix http://gcc.gnu.org/ml/fortran/2012-04/msg00082.html) - [Patch, Fortran] PR52864 - Fix pointer-intent regresssion http://gcc.gnu.org/ml/fortran/2012-04/msg00058.html Janus: - [Patch, Fortran, OOP] PR 52968: Call to type-bound procedure wrongly rejected http://gcc.gnu.org/ml/fortran/2012-04/msg00083.html Thomas: - [patch, fortran] Trim spaces on list-directed reads http://gcc.gnu.org/ml/fortran/2012-04/msg00040.html - [patch, fortran-dev] Use fixed variable sizes for stride calculations http://gcc.gnu.org/ml/fortran/2012-04/msg00074.html Bernhard: - [PATCH] gfortran testsuite: implicitly cleanup-modules, part 2 http://gcc.gnu.org/ml/fortran/2012-04/msg00065.html Janne: - [Patch, fortran] PR 49010/24518 MOD/MODULO fixes http://gcc.gnu.org/ml/fortran/2012-04/msg00012.html Okayed but haven't found best wording. * * * gfortran regression status: - PR52916 - [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build Fixed - except for followup test-suite fix - PR 52864 - [4.6/4.7/4.8 Regression] Assignment to pointer component ... rejects-valid. Approved patch, not yet committed. (Non regression issue: Patch submitted, pending review) - PR 52679 - [4.6 Regression] ICE in gfortran 4.6.3, x86_64 ice-on-valid-code. - PR 45586 - [4.8 Regression] ICE non-trivial conversion at assignment ice-checking (tree decl issue related to restricted pointers.) - PR49791 - [4.5/4.6/4.7/4.8 Regression] Formatted namelist reads fai... Special case remaining. Related to more serious namelist nonregression PR 51825 - PR50981 - [4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL... Mostly fixed. Could consider skipping the backporting. Some non-regressions still have to be fixed. - PR51520 - [4.6 Regression] ICE in gfortran 4.6.2, x86_64 ice-on-valid-code - PR52062 - [4.6 regression] public generic name, specific functions ... ice-on-valid-code - PR50410 - [4.6/4.7/4.8 Regression] ICE in record_reference ice-on-invalid-code Multiple data initialization, draft patch available - PR50105. [4.6/4.7/4.8 Regression] I/O with g6.5 - wrong number of ... wrong-code. Not a regression (according to J3, WG5 approval pending); missed diagnostic - PR 52158 - Regression on character function with gfortran 4.7 No true regression. Bogusly rejects previously working character(len=:), but the support was shaky. - PR 42954 - [4.5/4.6/4.7/4.8 regression] TARGET_*_CPP_BUILTINS issues... Tobias PS: I hope that I found all pending patches and correctly stated their status.
Re: [Patch, Fortran, OOP] PR 52968: Call to type-bound procedure wrongly rejected
Hi Tobias, here is a small patch for an OOP problem. For discussion see the PR. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK and thanks for the patch. thanks for the review. Committed as r186486. Note, however, that since Bernhard's patch*, using cleanup-modules is usually not needed. * http://gcc.gnu.org/ml/fortran/2012-03/msg00069.html Ah, good point. I forgot about that (removed the cleanup-modules before committing). Cheers, Janus 2012-04-15 Janus Weil ja...@gcc.gnu.org PR fortran/52968 * class.c (gfc_build_class_symbol): Make sure the 'f2k_derived' namespace is present. 2012-04-15 Janus Weil ja...@gcc.gnu.org PR fortran/52968 * gfortran.dg/typebound_call_23.f03: New test case.
Re: [PATCH] Fix PR52976
On Sat, Apr 14, 2012 at 7:05 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
This patch corrects two errors in reassociating expressions with
repeated factors. First, undistribution needs to recognize repeated
factors. For now, repeated factors will be ineligible for this
optimization. In the future, this can be improved. Second, when a
__builtin_powi call is introduced, its target SSA name must be given a
rank higher than other operands in the operand list. Otherwise, uses of
the call result may be introduced prior to the call.
Bootstrapped and regression tested on powerpc64-linux. Confirmed that
cpu2000 and cpu2006 SPEC tests build cleanly. OK for trunk?
Ok, given it fixes quite some fallout.
But I wonder why the rank computation does not properly work
automagically in the powi case.
Also for undistribution it looks like this might introduce missed optimizations?
Thus, how hard would it be to teach it to properly handle -count != 1? ISTR
it does some counting itself.
Thanks,
Richard.
Thanks,
Bill
2012-04-14 Bill Schmidt wschm...@linux.vnet.ibm.com
PR tree-optimization/52976
* tree-ssa-reassoc.c (add_to_ops_vec_max_rank): New function.
(undistribute_ops_list): Ops with repeat counts aren't eligible for
undistribution.
(attempt_builtin_powi): Call add_to_ops_vec_max_rank.
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 186393)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -544,6 +544,28 @@ add_repeat_to_ops_vec (VEC(operand_entry_t, heap)
reassociate_stats.pows_encountered++;
}
+/* Add an operand entry to *OPS for the tree operand OP, giving the
+ new entry a larger rank than any other operand already in *OPS. */
+
+static void
+add_to_ops_vec_max_rank (VEC(operand_entry_t, heap) **ops, tree op)
+{
+ operand_entry_t oe = (operand_entry_t) pool_alloc (operand_entry_pool);
+ operand_entry_t oe1;
+ unsigned i;
+ unsigned max_rank = 0;
+
+ FOR_EACH_VEC_ELT (operand_entry_t, *ops, i, oe1)
+ if (oe1-rank max_rank)
+ max_rank = oe1-rank;
+
+ oe-op = op;
+ oe-rank = max_rank + 1;
+ oe-id = next_operand_entry_id++;
+ oe-count = 1;
+ VEC_safe_push (operand_entry_t, heap, *ops, oe);
+}
+
/* Return true if STMT is reassociable operation containing a binary
operation with tree code CODE, and is inside LOOP. */
@@ -1200,6 +1222,7 @@ undistribute_ops_list (enum tree_code opcode,
dcode = gimple_assign_rhs_code (oe1def);
if ((dcode != MULT_EXPR
dcode != RDIV_EXPR)
+ || oe1-count != 1
|| !is_reassociable_op (oe1def, dcode, loop))
continue;
@@ -1243,6 +1266,8 @@ undistribute_ops_list (enum tree_code opcode,
oecount c;
void **slot;
size_t idx;
+ if (oe1-count != 1)
+ continue;
c.oecode = oecode;
c.cnt = 1;
c.id = next_oecount_id++;
@@ -1311,7 +1336,7 @@ undistribute_ops_list (enum tree_code opcode,
FOR_EACH_VEC_ELT (operand_entry_t, subops[i], j, oe1)
{
- if (oe1-op == c-op)
+ if (oe1-op == c-op oe1-count == 1)
{
SET_BIT (candidates2, i);
++nr_candidates2;
@@ -3275,8 +3300,10 @@ attempt_builtin_powi (gimple stmt, VEC(operand_ent
gsi_insert_before (gsi, pow_stmt, GSI_SAME_STMT);
}
- /* Append the result of this iteration to the ops vector. */
- add_to_ops_vec (ops, iter_result);
+ /* Append the result of this iteration to the ops vector.
+ Give it a rank higher than all other ranks in the ops vector
+ so that all uses of it will be forced to come after it. */
+ add_to_ops_vec_max_rank (ops, iter_result);
/* Decrement the occurrence count of each element in the product
by the count found above, and remove this many copies of each
Re: RFA: Remove ADDRESS handling from gen*.c
On Sun, Apr 15, 2012 at 5:09 PM, Richard Sandiford rdsandif...@googlemail.com wrote: ADDRESS has long had no meaning in .md files. This patch removes the associated gen* support. Borders on the obvious, but just to be sure: bootstrapped regression tested on x86_64-linux-gnu. OK to install? Ok. Thanks, Richard. Richard gcc/ * genemit.c (gen_exp): Remove ADDRESS handling. * genoutput.c (scan_operands): Likewise. * genpeep.c (match_rtx): Likewise. * genrecog.c (add_to_sequence): Likewise. Index: gcc/genemit.c === --- gcc/genemit.c 2012-03-06 19:20:53.0 + +++ gcc/genemit.c 2012-04-15 10:35:29.615548775 +0100 @@ -160,9 +160,6 @@ gen_exp (rtx x, enum rtx_code subroutine gen_rtx_scratch (x, subroutine_type); return; - case ADDRESS: - fatal (ADDRESS expression code used in named instruction pattern); - case PC: printf (pc_rtx); return; Index: gcc/genoutput.c === --- gcc/genoutput.c 2011-08-27 09:54:07.0 +0100 +++ gcc/genoutput.c 2012-04-15 10:35:29.617548777 +0100 @@ -510,10 +510,6 @@ scan_operands (struct data *d, rtx part, scan_operands (d, XVECEXP (part, 2, i), 0, 0); return; - case ADDRESS: - scan_operands (d, XEXP (part, 0), 1, 0); - return; - case STRICT_LOW_PART: scan_operands (d, XEXP (part, 0), 0, 1); return; Index: gcc/genpeep.c === --- gcc/genpeep.c 2011-08-27 09:54:07.0 +0100 +++ gcc/genpeep.c 2012-04-15 10:35:29.617548777 +0100 @@ -231,10 +231,6 @@ match_rtx (rtx x, struct link *path, int } return; - case ADDRESS: - match_rtx (XEXP (x, 0), path, fail_label); - return; - default: break; } Index: gcc/genrecog.c === --- gcc/genrecog.c 2011-08-27 09:54:07.0 +0100 +++ gcc/genrecog.c 2012-04-15 11:14:58.661416813 +0100 @@ -687,7 +687,6 @@ add_to_sequence (rtx pattern, struct dec sub = this_decision = new_decision (pos, last); place = this_decision-tests; - restart: mode = GET_MODE (pattern); code = GET_CODE (pattern); @@ -854,10 +853,6 @@ add_to_sequence (rtx pattern, struct dec test-u.dup = XINT (pattern, 0); goto fini; - case ADDRESS: - pattern = XEXP (pattern, 0); - goto restart; - default: break; }
Re: [doc] tm.texi: Move NO_DOLLAR_IN LABEL and NO_DOT_IN_LABEL to Label Output section (was: GCC 4.6.1 likes to rename my functions)
On Mon, Apr 16, 2012 at 2:10 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Wed, 6 Jul 2011, Paulo J. Matos wrote:
On 06/07/11 16:08, Richard Guenther wrote:
See cgraph.c:clone_function_name, it uses the NO_DOT_IN_LABEL and
NO_DOLLAR_IN_LABEL target macros and ASM_FORMAT_PRIVATE_NAME.
Why are NO_DOLLAR_IN LABEL and NO_DOT_IN_LABEL not listed in the Output
and Generation of Labels instead of Misc. The former sounds like it's
a better fit to describe these macros.
Because nobody moved them yet? ;-)
Richi, are you fine with this?
Yes.
Thanks,
Richard.
Gerald
2012-04-16 Gerald Pfeifer ger...@pfeifer.com
* doc/tm.texi (Misc): Move descriptions of NO_DOLLAR_IN_LABEL
and NO_DOT_IN_LABEL from here...
(Label Output): ...to here.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 186466)
+++ doc/tm.texi (working copy)
@@ -7842,6 +7842,20 @@
to redefine @code{ASM_OUTPUT_MEASURED_SIZE} to use some other technique.
@end defmac
+@defmac NO_DOLLAR_IN_LABEL
+Define this macro if the assembler does not accept the character
+@samp{$} in label names. By default constructors and destructors in
+G++ have @samp{$} in the identifiers. If this macro is defined,
+@samp{.} is used instead.
+@end defmac
+
+@defmac NO_DOT_IN_LABEL
+Define this macro if the assembler does not accept the character
+@samp{.} in label names. By default constructors and destructors in G++
+have names that use @samp{.}. If this macro is defined, these names
+are rewritten to avoid @samp{.}.
+@end defmac
+
@defmac TYPE_ASM_OP
A C string containing the appropriate assembler directive to specify the
type of a symbol, without any arguments. On systems that use ELF, the
@@ -10778,20 +10792,6 @@
there is no need to define this macro in that case.
@end defmac
-@defmac NO_DOLLAR_IN_LABEL
-Define this macro if the assembler does not accept the character
-@samp{$} in label names. By default constructors and destructors in
-G++ have @samp{$} in the identifiers. If this macro is defined,
-@samp{.} is used instead.
-@end defmac
-
-@defmac NO_DOT_IN_LABEL
-Define this macro if the assembler does not accept the character
-@samp{.} in label names. By default constructors and destructors in G++
-have names that use @samp{.}. If this macro is defined, these names
-are rewritten to avoid @samp{.}.
-@end defmac
-
@defmac INSN_SETS_ARE_DELAYED (@var{insn})
Define this macro as a C expression that is nonzero if it is safe for the
delay slot scheduler to place instructions in the delay slot of @var{insn},
[PATCH] Fix parts of PR52975
When looking at the code we produce from if-conversion and vectorization
I noticed several things. For one, we are not handling TARGET_MEM_REF
in operand_equal_p which means that DOM does not clean up loads/stores
of that form (to the extent DOM can do that anyway). Also we never
simplify the conditions in VEC_COND_EXPRs because the combining in
forwprop does not handle them. And we do not combine the inverted
COND_EXPRs if-conversion can create - but it's easy to do that in
forwprop.
The following addresses this two issues.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-04-16 Richard Guenther rguent...@suse.de
PR tree-optimization/52975
* tree-ssa-forwprop.c (combine_cond_exprs): New function.
(ssa_forward_propagate_and_combine): Call it for COND_EXPRs
and VEC_COND_EXPRs. Also combine into VEC_COND_EXPRs condition.
* fold-const.c (operand_equal_p): Handle TARGET_MEM_REF.
Index: gcc/tree-ssa-forwprop.c
===
*** gcc/tree-ssa-forwprop.c (revision 186417)
--- gcc/tree-ssa-forwprop.c (working copy)
*** forward_propagate_into_cond (gimple_stmt
*** 632,637
--- 632,689
return 0;
}
+ /* Propagate from the ssa name definition statements of COND_EXPR
+values in the rhs of statement STMT into the conditional arms
+if that simplifies it.
+Returns true if the stmt was changed. */
+
+ static bool
+ combine_cond_exprs (gimple_stmt_iterator *gsi_p)
+ {
+ gimple stmt = gsi_stmt (*gsi_p);
+ tree cond, val1, val2;
+ bool changed = false;
+
+ cond = gimple_assign_rhs1 (stmt);
+ val1 = gimple_assign_rhs2 (stmt);
+ if (TREE_CODE (val1) == SSA_NAME)
+ {
+ gimple def_stmt = SSA_NAME_DEF_STMT (val1);
+ if (is_gimple_assign (def_stmt)
+ gimple_assign_rhs_code (def_stmt) == gimple_assign_rhs_code (stmt)
+ operand_equal_p (gimple_assign_rhs1 (def_stmt), cond, 0))
+ {
+ val1 = unshare_expr (gimple_assign_rhs2 (def_stmt));
+ gimple_assign_set_rhs2 (stmt, val1);
+ changed = true;
+ }
+ }
+ val2 = gimple_assign_rhs3 (stmt);
+ if (TREE_CODE (val2) == SSA_NAME)
+ {
+ gimple def_stmt = SSA_NAME_DEF_STMT (val2);
+ if (is_gimple_assign (def_stmt)
+ gimple_assign_rhs_code (def_stmt) == gimple_assign_rhs_code (stmt)
+ operand_equal_p (gimple_assign_rhs1 (def_stmt), cond, 0))
+ {
+ val2 = unshare_expr (gimple_assign_rhs3 (def_stmt));
+ gimple_assign_set_rhs3 (stmt, val2);
+ changed = true;
+ }
+ }
+ if (operand_equal_p (val1, val2, 0))
+ {
+ gimple_assign_set_rhs_from_tree (gsi_p, val1);
+ stmt = gsi_stmt (*gsi_p);
+ changed = true;
+ }
+
+ if (changed)
+ update_stmt (stmt);
+
+ return changed;
+ }
+
/* We've just substituted an ADDR_EXPR into stmt. Update all the
relevant data structures to match. */
*** ssa_forward_propagate_and_combine (void)
*** 2480,2489
|| code == NEGATE_EXPR)
TREE_CODE (rhs1) == SSA_NAME)
changed = simplify_not_neg_expr (gsi);
! else if (code == COND_EXPR)
{
/* In this case the entire COND_EXPR is in rhs1. */
changed |= forward_propagate_into_cond (gsi);
stmt = gsi_stmt (gsi);
}
else if (TREE_CODE_CLASS (code) == tcc_comparison)
--- 2532,2543
|| code == NEGATE_EXPR)
TREE_CODE (rhs1) == SSA_NAME)
changed = simplify_not_neg_expr (gsi);
! else if (code == COND_EXPR
!|| code == VEC_COND_EXPR)
{
/* In this case the entire COND_EXPR is in rhs1. */
changed |= forward_propagate_into_cond (gsi);
+ changed |= combine_cond_exprs (gsi);
stmt = gsi_stmt (gsi);
}
else if (TREE_CODE_CLASS (code) == tcc_comparison)
Index: gcc/fold-const.c
===
*** gcc/fold-const.c(revision 186417)
--- gcc/fold-const.c(working copy)
*** operand_equal_p (const_tree arg0, const_
*** 2562,2567
--- 2562,2575
case IMAGPART_EXPR:
return OP_SAME (0);
+ case TARGET_MEM_REF:
+ /* Require equal extra operands and then fall thru to MEM_REF
+handling of the two common operands. */
+ if (!OP_SAME_WITH_NULL (2)
+ || !OP_SAME_WITH_NULL (3)
+ || !OP_SAME_WITH_NULL (4))
+ return 0;
+ /* Fallthru. */
case MEM_REF:
/* Require equal access sizes, and similar pointer types.
We can have incomplete types for array
[testsuite] Fix plugin testsuite, remove uses of TODO_dump_func (PR testsuite/52948)
As reported in PR testsuite/52948, several plugin testcases were failing since the removal of TODO_dump_func: UNRESOLVED: selfassign.c compilation, -I. -I/vol/gcc/src/hg/trunk/local/gcc/testsuite -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../gcc -I/var/gcc/regression/trunk/11-gcc/build/gcc/testsuite/g++/../../../gcc -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../include -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../libcpp/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/include -I/var/gcc/regression/trunk/11-gcc/build/gcc/testsuite/g++/../../../intl -O -DIN_GCC -fPIC -shared I have no idea why this has been missed when testing the removal patch, because the failures are very prominent in mail-report.log (maybe because the incorrectly show up as UNRESOLVED instead of FAIL). This patch fixes this by removing the uses of TODO_dump_func from the affected plugins. At the same time, I'm finally fixing some issues with the plugin tests that have annoyed me for quite some time: * The tests should log the full (relative) path to the testcase, not only the basenames. * Using unresolved to report failures to compile the plugins is wrong: this should be fail instead, and the pass case needs to be logged as well. * There's no point in logging the options used to compile the plugin: they are completely internal to plugin-support.exp and not in any way influenced by the testsuite drivers. There's one issue I didn't fix due to the large number of (bad) precedents in the testsuite: * If a plugin fails to compile, the compilations using it should become unresolved instead of just returning early. Bootstrapped without regressions on i386-pc-solaris2.11, installed on mainline. Rainer 2012-04-14 Rainer Orth r...@cebitec.uni-bielefeld.de gcc/testsuite: * lib/plugin-support.exp (plugin-test-execute): Properly determine testcase name. Use fail, pass instead of unresolved. Don't log $optstr. PR testsuite/52948 * g++.dg/plugin/dumb_plugin.c (pass_dumb_plugin_example): Remove TODO_dump_func. * g++.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise. * gcc.dg/plugin/one_time_plugin.c (one_pass): Likewise. * gcc.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise. # HG changeset patch # Parent 12b8d919dd25eba78689a9fef617cc5428a57c33 Fix plugin testsuite, uses of TODO_dump_func diff --git a/gcc/testsuite/g++.dg/plugin/dumb_plugin.c b/gcc/testsuite/g++.dg/plugin/dumb_plugin.c --- a/gcc/testsuite/g++.dg/plugin/dumb_plugin.c +++ b/gcc/testsuite/g++.dg/plugin/dumb_plugin.c @@ -72,7 +72,7 @@ static struct gimple_opt_pass pass_dumb_ 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ -TODO_dump_func/* todo_flags_finish */ +0 /* todo_flags_finish */ } }; diff --git a/gcc/testsuite/g++.dg/plugin/selfassign.c b/gcc/testsuite/g++.dg/plugin/selfassign.c --- a/gcc/testsuite/g++.dg/plugin/selfassign.c +++ b/gcc/testsuite/g++.dg/plugin/selfassign.c @@ -276,7 +276,7 @@ static struct gimple_opt_pass pass_warn_ 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ -TODO_dump_func/* todo_flags_finish */ +0 /* todo_flags_finish */ } }; diff --git a/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c b/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c --- a/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c +++ b/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c @@ -42,7 +42,7 @@ struct gimple_opt_pass one_pass = 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ - TODO_dump_func/* todo_flags_finish */ + 0 /* todo_flags_finish */ } }; diff --git a/gcc/testsuite/gcc.dg/plugin/selfassign.c b/gcc/testsuite/gcc.dg/plugin/selfassign.c --- a/gcc/testsuite/gcc.dg/plugin/selfassign.c +++ b/gcc/testsuite/gcc.dg/plugin/selfassign.c @@ -276,7 +276,7 @@ static struct gimple_opt_pass pass_warn_ 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ -TODO_dump_func/* todo_flags_finish */ +0 /* todo_flags_finish */ } }; diff --git a/gcc/testsuite/lib/plugin-support.exp b/gcc/testsuite/lib/plugin-support.exp --- a/gcc/testsuite/lib/plugin-support.exp +++ b/gcc/testsuite/lib/plugin-support.exp @@ -1,4 +1,4 @@ -# Copyright (C) 2009, 2010 Free Software Foundation, Inc.
Use target_alias in validate_failures.py
When I tried contrib/testsuite-management/validate_failures.py for the
first time this weekend, I ran into the following problem: while it
works fine for a i386-pc-solaris2.11 bootstrap, it fails instead for a
amd64-pc-solaris2.11 bootstrap:
error: 11-gcc-64/build is not a valid GCC top level build directory.
The problem is that while the toplevel Makefile has
target=x86_64-pc-solaris2.11
the build was configured with --target=amd64-pc-solaris2.11 and the
target libraries live below the amd64-pc-solaris2.11, using the target
alias instead of the canonical target name. Therefore the script thould
use
target_alias=amd64-pc-solaris2.11
to work in such a case.
The following patch does just that.
Ok for mainline?
Btw., it occured to me that it might be useful to add an option to
locate out-of-tree manifests. I often have several source trees
(unmodified sources, ones with local patches) and would like to share
manifests between them. While this can be achieved with symlinks, a
--manifest_dir or similar option might be an alternative. Thoughts?
Rainer
2012-04-15 Rainer Orth r...@cebitec.uni-bielefeld.de
* testsuite-management/validate_failures.py (GetBuildData): Use
target_alias.
# HG changeset patch
# Parent 84699f134dedb823eb7ecde316543a2870d1b47a
Use target_alias in validate_failures.py
diff --git a/contrib/testsuite-management/validate_failures.py b/contrib/testsuite-management/validate_failures.py
--- a/contrib/testsuite-management/validate_failures.py
+++ b/contrib/testsuite-management/validate_failures.py
@@ -5,7 +5,7 @@
# Contributed by Diego Novillo dnovi...@google.com
#
-# Copyright (C) 2011 Free Software Foundation, Inc.
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
#
# This file is part of GCC.
#
@@ -241,7 +241,7 @@ def CompareResults(manifest, actual):
def GetBuildData(options):
- target = GetMakefileValue('%s/Makefile' % options.build_dir, 'target=')
+ target = GetMakefileValue('%s/Makefile' % options.build_dir, 'target_alias=')
srcdir = GetMakefileValue('%s/Makefile' % options.build_dir, 'srcdir =')
if not ValidBuildDirectory(options.build_dir, target):
Error('%s is not a valid GCC top level build directory.' %
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fix PR52975
This fixes the missed cleanup opportunities from the if-conversion mess.
We should try to produce consistent predicates - thus not do overly
optimistic simplifications on them.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-04-16 Richard Guenther rguent...@suse.de
PR tree-optimization/52975
* tree-if-conv.c (predicate_bbs): Do not simplify inverted
condition but always mark it with TRUTH_NOT_EXPR.
Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c (revision 186487)
+++ gcc/tree-if-conv.c (working copy)
@@ -968,7 +968,7 @@ predicate_bbs (loop_p loop)
case GIMPLE_COND:
{
- tree c2, tem;
+ tree c2;
edge true_edge, false_edge;
location_t loc = gimple_location (stmt);
tree c = fold_build2_loc (loc, gimple_cond_code (stmt),
@@ -986,10 +986,8 @@ predicate_bbs (loop_p loop)
unshare_expr (c));
/* If C is false, then FALSE_EDGE is taken. */
- c2 = invert_truthvalue_loc (loc, unshare_expr (c));
- tem = canonicalize_cond_expr_cond (c2);
- if (tem)
- c2 = tem;
+ c2 = build1_loc (loc, TRUTH_NOT_EXPR,
+boolean_type_node, unshare_expr (c));
add_to_dst_predicate_list (loop, false_edge,
unshare_expr (cond), c2);
Re: [PATCH] Fix PR52976
On Mon, 2012-04-16 at 11:01 +0200, Richard Guenther wrote:
On Sat, Apr 14, 2012 at 7:05 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
This patch corrects two errors in reassociating expressions with
repeated factors. First, undistribution needs to recognize repeated
factors. For now, repeated factors will be ineligible for this
optimization. In the future, this can be improved. Second, when a
__builtin_powi call is introduced, its target SSA name must be given a
rank higher than other operands in the operand list. Otherwise, uses of
the call result may be introduced prior to the call.
Bootstrapped and regression tested on powerpc64-linux. Confirmed that
cpu2000 and cpu2006 SPEC tests build cleanly. OK for trunk?
Ok, given it fixes quite some fallout.
OK, thanks.
But I wonder why the rank computation does not properly work
automagically in the powi case.
The reassociator generally tries to replace expressions in place unless
the rank system tells it otherwise. At the moment, __builtin_powi calls
are added right before the root of the reassociation chain (the last
multiply). In the cases that failed, the natural rank of the call was
one greater than the rank of the repeated factors, and there were other
factors with higher rank than that. So the call was in the middle of
the ranks but placement required it to have the highest rank. Because
the call can't be further reassociated, it sort of ruins the flexibility
of the rank system's placement algorithm.
It would probably be better to insert the calls as early as necessary,
but no earlier, to properly order things while letting the rank system
do its job normally. That would help reduce lifetimes of reassociated
values. I didn't see an obvious way to do that with a quick fix; I'm
planning to think about it some more.
Also for undistribution it looks like this might introduce missed
optimizations?
Thus, how hard would it be to teach it to properly handle -count != 1? ISTR
it does some counting itself.
I'm planning to work on that as well. I looked at it enough over the
weekend to know it wasn't completely trivial, so I wanted to get the
problem papered over for now. It shouldn't be too hard to get right.
Thanks,
Bill
Thanks,
Richard.
Thanks,
Bill
2012-04-14 Bill Schmidt wschm...@linux.vnet.ibm.com
PR tree-optimization/52976
* tree-ssa-reassoc.c (add_to_ops_vec_max_rank): New function.
(undistribute_ops_list): Ops with repeat counts aren't eligible for
undistribution.
(attempt_builtin_powi): Call add_to_ops_vec_max_rank.
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 186393)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -544,6 +544,28 @@ add_repeat_to_ops_vec (VEC(operand_entry_t, heap)
reassociate_stats.pows_encountered++;
}
+/* Add an operand entry to *OPS for the tree operand OP, giving the
+ new entry a larger rank than any other operand already in *OPS. */
+
+static void
+add_to_ops_vec_max_rank (VEC(operand_entry_t, heap) **ops, tree op)
+{
+ operand_entry_t oe = (operand_entry_t) pool_alloc (operand_entry_pool);
+ operand_entry_t oe1;
+ unsigned i;
+ unsigned max_rank = 0;
+
+ FOR_EACH_VEC_ELT (operand_entry_t, *ops, i, oe1)
+if (oe1-rank max_rank)
+ max_rank = oe1-rank;
+
+ oe-op = op;
+ oe-rank = max_rank + 1;
+ oe-id = next_operand_entry_id++;
+ oe-count = 1;
+ VEC_safe_push (operand_entry_t, heap, *ops, oe);
+}
+
/* Return true if STMT is reassociable operation containing a binary
operation with tree code CODE, and is inside LOOP. */
@@ -1200,6 +1222,7 @@ undistribute_ops_list (enum tree_code opcode,
dcode = gimple_assign_rhs_code (oe1def);
if ((dcode != MULT_EXPR
dcode != RDIV_EXPR)
+ || oe1-count != 1
|| !is_reassociable_op (oe1def, dcode, loop))
continue;
@@ -1243,6 +1266,8 @@ undistribute_ops_list (enum tree_code opcode,
oecount c;
void **slot;
size_t idx;
+ if (oe1-count != 1)
+ continue;
c.oecode = oecode;
c.cnt = 1;
c.id = next_oecount_id++;
@@ -1311,7 +1336,7 @@ undistribute_ops_list (enum tree_code opcode,
FOR_EACH_VEC_ELT (operand_entry_t, subops[i], j, oe1)
{
- if (oe1-op == c-op)
+ if (oe1-op == c-op oe1-count == 1)
{
SET_BIT (candidates2, i);
++nr_candidates2;
@@ -3275,8 +3300,10 @@ attempt_builtin_powi (gimple stmt, VEC(operand_ent
gsi_insert_before (gsi, pow_stmt, GSI_SAME_STMT);
}
- /* Append the result of this iteration to the ops vector. */
- add_to_ops_vec (ops, iter_result);
+ /* Append the result
Re: [PATCH][ARM] NEON DImode neg
On 14/04/12 14:11, Andrew Stubbs wrote: And now with the patch. :( On 14/04/12 13:48, Andrew Stubbs wrote: On 12/04/12 16:48, Richard Earnshaw wrote: If negation in Neon needs a scratch register, it seems to me to be somewhat odd that we're disparaging the ARM version. Also, wouldn't it be sensible to support a variant that was early-clobber on operand 0, but loaded immediate zero into that value first: vmov Dd, #0 vsub Dd, Dd, Dm That way you'll never need more than two registers, whereas today you want three. This patch implements the changes you suggested. I've done a full bootstrap and test and found no regressions. OK? Andrew P.S. This patch can't actually be committed until my NEON DImode immediate constants patch is approved and committed. (Without that the load #0 needs a constant pool, and loading constants this late has a bug at -O0.) neon-neg64.patch 2012-04-12 Andrew Stubbs a...@codesourcery.com gcc/ * config/arm/arm.md (negdi2): Use gen_negdi2_neon. * config/arm/neon.md (negdi2_neon): New insn. Also add splitters for core and NEON registers. OK R.
Re: [PATCH][configure] Make sure CFLAGS_FOR_TARGET And CXXFLAGS_FOR_TARGET contain -O2
Ping? On 29.03.2012 13:48, Christophe Lyon wrote: Hello, According to a comment in configure/configure.ac: # We want to ensure that TARGET libraries (which we know are built with # gcc) are built with -O2 -g, so include those options when setting # CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET. but the current code does not ensure this. I propose the patch below to fix this. 2012-03-29 Christophe Lyonchristophe.l...@st.com * configure.ac (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Make sure they contain -O2. * configure: Regenerate. Index: configure.ac === --- configure.ac(revision 2515) +++ configure.ac(working copy) @@ -2223,7 +2223,7 @@ if test x$CFLAGS_FOR_TARGET = x; then esac case $CFLAGS in * -g * | * -g3 *) ;; -*) CFLAGS_FOR_TARGET=-g $CFLAGS ;; +*) CFLAGS_FOR_TARGET=-g $CFLAGS_FOR_TARGET ;; esac fi AC_SUBST(CFLAGS_FOR_TARGET) @@ -2236,7 +2236,7 @@ if test x$CXXFLAGS_FOR_TARGET = x; the esac case $CXXFLAGS in * -g * | * -g3 *) ;; -*) CXXFLAGS_FOR_TARGET=-g $CXXFLAGS ;; +*) CXXFLAGS_FOR_TARGET=-g $CXXFLAGS_FOR_TARGET ;; esac fi AC_SUBST(CXXFLAGS_FOR_TARGET) Index: configure === --- configure(revision 2515) +++ configure(working copy) @@ -6739,7 +6739,7 @@ if test x$CFLAGS_FOR_TARGET = x; then esac case $CFLAGS in * -g * | * -g3 *) ;; -*) CFLAGS_FOR_TARGET=-g $CFLAGS ;; +*) CFLAGS_FOR_TARGET=-g $CFLAGS_FOR_TARGET ;; esac fi @@ -6752,7 +6751,7 @@ if test x$CXXFLAGS_FOR_TARGET = x; the esac case $CXXFLAGS in * -g * | * -g3 *) ;; -*) CXXFLAGS_FOR_TARGET=-g $CXXFLAGS ;; +*) CXXFLAGS_FOR_TARGET=-g $CXXFLAGS_FOR_TARGET ;; esac fi .
[PATCH] Fix PR52977
This fixes PR52977 - for PCH to work with its pointer relocation code
we have to avoid dereferencing pointers to compute array lengths
in structures. So we have to unfortunately keep duplicated info about
VECTOR_CST vector lengths.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-04-16 Richard Guenther rguent...@suse.de
PR middle-end/52977
* tree.h (VECTOR_CST_NELTS): Adjust.
(struct tree_vector): Add explicit length field.
(make_vector_stat): Declare.
(make_vector): Define.
* tree.c (make_vector_stat): New function.
(build_vector_stat): Use it.
* tree-streamer-in.c (streamer_alloc_tree): Likewise.
Index: gcc/tree.c
===
*** gcc/tree.c (revision 186491)
--- gcc/tree.c (working copy)
*** cst_and_fits_in_hwi (const_tree x)
*** 1315,1320
--- 1315,1339
|| TREE_INT_CST_HIGH (x) == -1);
}
+ /* Build a newly constructed TREE_VEC node of length LEN. */
+
+ tree
+ make_vector_stat (unsigned len MEM_STAT_DECL)
+ {
+ tree t;
+ unsigned length = (len - 1) * sizeof (tree) + sizeof (struct tree_vector);
+
+ record_node_allocation_statistics (VECTOR_CST, length);
+
+ t = ggc_alloc_zone_cleared_tree_node_stat (tree_zone, length
PASS_MEM_STAT);
+
+ TREE_SET_CODE (t, VECTOR_CST);
+ TREE_CONSTANT (t) = 1;
+ VECTOR_CST_NELTS (t) = len;
+
+ return t;
+ }
+
/* Return a new VECTOR_CST node whose type is TYPE and whose values
are in a list pointed to by VALS. */
*** build_vector_stat (tree type, tree *vals
*** 1323,1338
{
int over = 0;
unsigned cnt = 0;
! tree v;
! int length = ((TYPE_VECTOR_SUBPARTS (type) - 1) * sizeof (tree)
! + sizeof (struct tree_vector));
!
! record_node_allocation_statistics (VECTOR_CST, length);
!
! v = ggc_alloc_zone_cleared_tree_node_stat (tree_zone, length
PASS_MEM_STAT);
!
! TREE_SET_CODE (v, VECTOR_CST);
! TREE_CONSTANT (v) = 1;
TREE_TYPE (v) = type;
/* Iterate through elements and check for overflow. */
--- 1342,1348
{
int over = 0;
unsigned cnt = 0;
! tree v = make_vector (TYPE_VECTOR_SUBPARTS (type));
TREE_TYPE (v) = type;
/* Iterate through elements and check for overflow. */
Index: gcc/tree.h
===
*** gcc/tree.h (revision 186491)
--- gcc/tree.h (working copy)
*** struct GTY(()) tree_complex {
*** 1534,1546
};
/* In a VECTOR_CST node. */
! #define VECTOR_CST_NELTS(NODE) (TYPE_VECTOR_SUBPARTS (TREE_TYPE (NODE)))
#define VECTOR_CST_ELTS(NODE) (VECTOR_CST_CHECK (NODE)-vector.elts)
#define VECTOR_CST_ELT(NODE,IDX) (VECTOR_CST_CHECK (NODE)-vector.elts[IDX])
struct GTY(()) tree_vector {
struct tree_typed typed;
! tree GTY ((length (TYPE_VECTOR_SUBPARTS (TREE_TYPE ((tree)%h)
elts[1];
};
#include symtab.h
--- 1534,1547
};
/* In a VECTOR_CST node. */
! #define VECTOR_CST_NELTS(NODE) (VECTOR_CST_CHECK (NODE)-vector.length)
#define VECTOR_CST_ELTS(NODE) (VECTOR_CST_CHECK (NODE)-vector.elts)
#define VECTOR_CST_ELT(NODE,IDX) (VECTOR_CST_CHECK (NODE)-vector.elts[IDX])
struct GTY(()) tree_vector {
struct tree_typed typed;
! unsigned length;
! tree GTY ((length (%h.length))) elts[1];
};
#include symtab.h
*** build_int_cstu (tree type, unsigned HOST
*** 4341,4346
--- 4342,4349
extern tree build_int_cst (tree, HOST_WIDE_INT);
extern tree build_int_cst_type (tree, HOST_WIDE_INT);
extern tree build_int_cst_wide (tree, unsigned HOST_WIDE_INT, HOST_WIDE_INT);
+ extern tree make_vector_stat (unsigned MEM_STAT_DECL);
+ #define make_vector(n) make_vector_stat (n MEM_STAT_INFO)
extern tree build_vector_stat (tree, tree * MEM_STAT_DECL);
#define build_vector(t,v) build_vector_stat (t, v MEM_STAT_INFO)
extern tree build_vector_from_ctor (tree, VEC(constructor_elt,gc) *);
Index: gcc/tree-streamer-in.c
===
*** gcc/tree-streamer-in.c (revision 186491)
--- gcc/tree-streamer-in.c (working copy)
*** streamer_alloc_tree (struct lto_input_bl
*** 476,485
else if (CODE_CONTAINS_STRUCT (code, TS_VECTOR))
{
HOST_WIDE_INT len = streamer_read_hwi (ib);
! result = ggc_alloc_zone_cleared_tree_node ((len - 1) * sizeof (tree)
!+ sizeof (struct tree_vector),
!tree_zone);
! TREE_SET_CODE (result, VECTOR_CST);
}
else if (CODE_CONTAINS_STRUCT (code, TS_BINFO))
{
--- 476,482
else if (CODE_CONTAINS_STRUCT (code, TS_VECTOR))
{
HOST_WIDE_INT len = streamer_read_hwi (ib);
! result = make_vector (len);
}
else if (CODE_CONTAINS_STRUCT (code, TS_BINFO))
{
Re: [PATCH] Fix PR52977
On Mon, Apr 16, 2012 at 3:19 PM, Richard Guenther rguent...@suse.de wrote: This fixes PR52977 - for PCH to work with its pointer relocation code we have to avoid dereferencing pointers to compute array lengths in structures. So we have to unfortunately keep duplicated info about VECTOR_CST vector lengths. Maybe add a FIXME for when pph hits trunk? Ciao! Steven
Re: [PATCH] Fix PR52977
On Mon, 16 Apr 2012, Steven Bosscher wrote: On Mon, Apr 16, 2012 at 3:19 PM, Richard Guenther rguent...@suse.de wrote: This fixes PR52977 - for PCH to work with its pointer relocation code we have to avoid dereferencing pointers to compute array lengths in structures. So we have to unfortunately keep duplicated info about VECTOR_CST vector lengths. Maybe add a FIXME for when pph hits trunk? I'm not sure PPH will replace PCH - will it? Richard.
Re: RFA: always supply a mode to plus_constant
On 15/04/12 10:29, Richard Sandiford wrote: As mentioned in the discussion of Mike's 2HWI patch, plus_constant is AFAIK the only rtl routine that handles arithmetic on CONST_INT without specifying the mode of the CONST_INT. That means it isn't always able to generate the right result. E.g. it returns 0x80 for a QImode add of 0x7f and 0x1, whereas the correct result is 0xffff80. Mike's patch therefore introduced plus_constant_mode. This allowed the routine to call itself recursively for CONST_INTs embedded in PLUSes, rather than having to treat them as a special case. This patch fixes the FIXME introduced in that patch: that all callers really ought to specify the mode. It's true that many callers are known to pass a register, but rather than try to justify on a case-by-case basis why a mode doesn't need to be passed, it seems better to always pass one. Most other rtl routines (e.g. the simplify_* ones) work in just the same way. One way of doing this would have been to semd patches that make individual files use plus_constant_mode. Then, once all the calls had been converted, and nothing called plus_constant, we could mechanically rename plus_constant_mode to plus_constant (because the _mode would be redundant, and inconsistent with things like the simplify routines). But that would mean a lot of SVN churn. Many calls to plus_constant are pressed up against the right side of the screen, and would need to be reformatted for the longer name. Then the mechanical rename would have to reformat them again, in many cases going back to the original. So I think the best way is simply to do the whole thing as one patch. Which means it needs a GWP... I did actually develop the patch by renaming the function (so that grep would tell me if I'd caught all calls) then renaming it back. If there are strong objections to doing it in one step, I can go back to that. Bootstrapped regression-tested on x86_64-linux-gnu. Also tested by compiling gcc for the following targets and making sure that the output of the gcc.c-torture and gcc.dg testsuites were the same at -O3 -g: alpha-linux-gnu arm-linux-gnueabi avr-rtems bfin-elf c6x-elf cr16-elf cris-elf epiphany-elf fr30-elf frv-linux-gnu h8300-elf ia64-linux-gnu iq2000-elf lm32-elf m32c-elf m32r-elf m68k-linux-gnu mcore-elf mep-elf microblaze-elf mips-linux-gnu mmix mn10300-elf moxie-elf hppa64-hp-hpux11.23 pdp11 picochip-elf powerpc-linux-gnu powerpc-eabispe rl78-elf rx-elf s390-linux-gnu score-elf sh-linux-gnu sparc-linux-gnu spu-elf tilegx-elf tilepro-elf xstormy16-elf v850-elf vax-netbsdelf xtensa-elf OK to install? Richard The ARM bits are OK. R. gcc/ * rtl.h (plus_constant, plus_constant_mode): Merge into a single plus_constant function. * explow.c (plus_constant, plus_constant_mode): Likewise. Assert that the mode is sensible. (use_anchored_address, round_push, allocate_dynamic_stack_space) (probe_stack_range, anti_adjust_stack_and_probe): Update calls to plus_constant. * alias.c (canon_rtx): Likewise. (init_alias_analysis): Likewise. * builtins.c (expand_builtin_return_addr) (expand_builtin_setjmp_setup, expand_builtin_longjmp) (expand_builtin_nonlocal_goto, expand_builtin_update_setjmp_buf) (expand_builtin_apply_args_1, expand_builtin_apply, expand_movstr) (expand_builtin_stpcpy): Likewise. * calls.c (save_fixed_argument_area, restore_fixed_argument_area) (compute_argument_addresses, internal_arg_pointer_based_exp) (expand_call, emit_library_call_value_1): Likewise. * cfgexpand.c (expand_one_stack_var_at, expand_debug_expr): Likewise. * combine-stack-adj.c (try_apply_stack_adjustment): Likewise. * combine.c (combine_simplify_rtx, force_to_mode): Likewise. * cse.c (insert_const_anchor, find_reg_offset_for_const) (use_related_value, fold_rtx): Likewise. * cselib.c (cselib_subst_to_values): Likewise. * dse.c (record_store, check_mem_read_rtx): Likewise. * dwarf2out.c (rtl_for_decl_location, gen_variable_die): Likewise. * emit-rtl.c (adjust_address_1): Likewise. * except.c (sjlj_emit_function_enter) (expand_builtin_extract_return_addr) (expand_builtin_frob_return_addr): Likewise. * expmed.c (expand_divmod): Likewise. * expr.c (move_by_pieces, store_by_pieces, store_by_pieces_1) (emit_move_resolve_push, push_block, emit_push_insn, store_expr) (expand_expr_addr_expr_1, expand_expr_real_1): Likewise. * function.c (assign_stack_local_1) (instantiate_virtual_regs_in_rtx): Likewise. * optabs.c (prepare_cmp_insn): Likewise. * recog.c (offsettable_address_addr_space_p): Likewise. * reload.c
Re: [PATCH] Fix PR52977
On Mon, Apr 16, 2012 at 10:23, Richard Guenther rguent...@suse.de wrote: On Mon, 16 Apr 2012, Steven Bosscher wrote: On Mon, Apr 16, 2012 at 3:19 PM, Richard Guenther rguent...@suse.de wrote: This fixes PR52977 - for PCH to work with its pointer relocation code we have to avoid dereferencing pointers to compute array lengths in structures. So we have to unfortunately keep duplicated info about VECTOR_CST vector lengths. Maybe add a FIXME for when pph hits trunk? I'm not sure PPH will replace PCH - will it? In theory, it may. But it's not in the immediate plans. The big thing that PCH has going for it is load speed. PCH is almost instantaneous, PPH isn't. A 1Gb PCH file can be restored in 1s, the corresponding PPH file needs ~8s to restore. The implementation can still be tuned for performance, but it will never be as fast as a couple of mmap operations. PPH is a much smaller representation (that 1Gb PCH file can be represented in 400Mb in PPH) and more flexible (almost any arbitrary subset of headers can be turned into separate PPH images). So, it's not clear whether we will want to replace PCH with PPH. Flexibility costs raw performance. If the performance gap can be bridged, we may want to consider it in the future. Diego.
Re: [PATCH] Fix PR52977
On Mon, 16 Apr 2012, Diego Novillo wrote: On Mon, Apr 16, 2012 at 10:23, Richard Guenther rguent...@suse.de wrote: On Mon, 16 Apr 2012, Steven Bosscher wrote: On Mon, Apr 16, 2012 at 3:19 PM, Richard Guenther rguent...@suse.de wrote: This fixes PR52977 - for PCH to work with its pointer relocation code we have to avoid dereferencing pointers to compute array lengths in structures. So we have to unfortunately keep duplicated info about VECTOR_CST vector lengths. Maybe add a FIXME for when pph hits trunk? I'm not sure PPH will replace PCH - will it? In theory, it may. But it's not in the immediate plans. The big thing that PCH has going for it is load speed. PCH is almost instantaneous, PPH isn't. A 1Gb PCH file can be restored in 1s, the corresponding PPH file needs ~8s to restore. The implementation can still be tuned for performance, but it will never be as fast as a couple of mmap operations. PPH is a much smaller representation (that 1Gb PCH file can be represented in 400Mb in PPH) and more flexible (almost any arbitrary subset of headers can be turned into separate PPH images). So, it's not clear whether we will want to replace PCH with PPH. Flexibility costs raw performance. If the performance gap can be bridged, we may want to consider it in the future. Well, the number one advantage of replacing PCH is that it would kill the current PCH implementation which is tied to our garbage collector... Richard.
Symbol table 5/many: Introduce symtab.c and commonize linked list of symbol table entries
Hi,
this patch starts with process of commonizing code that should be in symtab.c.
It moves linked lists out of cgraph and varpool nodes into the symbol base
type and compensates all remaining places we walk the lists directly to use
the accessor functions.
Finally bit of benefits and code unification...
Bootstrapped/regtested x86_64-linux, will commit it shortly.
* cgraph.h (symtab_node_base): Add next and previous pointers.
(cgraph_node): Remove next and preivous pointers.
(varpool_node): Likewise; remove next/previous GTY marker;
it is not type safe.
(symtab_node_def): Update GTY marker
(x_cgraph_nodes, cgraph_nodes): Remove.
(symtab_nodes): New function.
(cgraph_order): Rename to ...
(symtab_order): ... this one.
(symtab_register_node, symtab_unregister_node, symtab_remove_node):
Declare.
(x_varpool_nodes, varpool_nodes): Remove.
(FOR_EACH_STATIC_VARIABLE): Update.
(symtab_function_p, symtab_variable_p): New function.
(FOR_EACH_VARIABLE): Update.
(varpool_first_variable, varpool_next_variable): New functions.
(FOR_EACH_VARIABLE): Update.
(cgraph_first_defined_function): Update.
(cgraph_next_defined_function, cgraph_next_defined_function): Update.
(FOR_EACH_DEFINED_FUNCTION, FOR_EACH_FUNCTION): Update.
(cgraph_first_function, cgraph_next_function): New.
(FOR_EACH_FUNCTION): Update.
(cgraph_first_function_with_gimple_body,
cgraph_next_function_with_gimple_body): Update.
* symtab.c: New file.
* cgraph.c: Update copyright dates.
(x_cgraph_nodes, cgraph_order): Remove.
(NEXT_FREE_NODE): Update.
(SET_NEXT_FREE_NODE): New.
(cgraph_create_node_1): Remove common code.
(cgraph_create_node); Remove common code; call symtab_register_node.
(cgraph_remove_node): Remove common code; call symtab_unregister-node.
(cgraph_add_asm_node); update.
(cgraph_clone_node): Register new node.
* cgraphunit.c (process_function_and_variable_attributes): Update.
(cgraph_analyze_functions): Update.
(cgraph_analyze_functions): Update.
(cgraph_output_in_order): Update.
* lto-cgraph.c (input_node, input_varpool_node, input_cgraph_1): Update.
* ipa-inline.c (recursive_inlining); update.
* lto-streamer-in.c (lto_input_toplevel_asms); Update.
* ipa.c (cgraph_remove_unreachable_nodes): Update.
* Makefile.in: Add symtab.o
* varpool.c (x_varpool_nodes): Remove
(varpool_node): Remove common code; call symtab_register_node.
(varpool_remove_node); Remove common code; call symtab_unregister_node.
Index: cgraph.h
===
*** cgraph.h(revision 186492)
--- cgraph.h(working copy)
*** struct GTY(()) symtab_node_base
*** 57,62
--- 57,66
/* File stream where this node is being written to. */
struct lto_file_decl_data * lto_file_data;
+ /* Linked list of symbol table entries starting with symtab_nodes. */
+ symtab_node next;
+ symtab_node previous;
+
PTR GTY ((skip)) aux;
/* Set when function has address taken.
*** struct GTY(()) cgraph_node {
*** 190,201
struct symtab_node_base symbol;
struct cgraph_edge *callees;
struct cgraph_edge *callers;
- struct cgraph_node *
- GTY ((nested_ptr (union symtab_node_def, (struct cgraph_node *)(%h),
(symtab_node)%h)))
- next;
- struct cgraph_node *
- GTY ((nested_ptr (union symtab_node_def, (struct cgraph_node *)(%h),
(symtab_node)%h)))
- previous;
/* List of edges representing indirect calls with a yet undetermined
callee. */
struct cgraph_edge *indirect_calls;
--- 194,199
*** DEF_VEC_ALLOC_P(cgraph_edge_p,heap);
*** 417,433
/* The varpool data structure.
Each static variable decl has assigned varpool_node. */
! struct GTY((chain_next (%h.next), chain_prev (%h.prev))) varpool_node {
struct symtab_node_base symbol;
/* For aliases points to declaration DECL is alias of. */
tree alias_of;
- /* Pointer to the next function in varpool_nodes. */
- struct varpool_node *
- GTY ((nested_ptr (union symtab_node_def, (struct varpool_node *)(%h),
(symtab_node)%h)))
- next;
- struct varpool_node *
- GTY ((nested_ptr (union symtab_node_def, (struct varpool_node *)(%h),
(symtab_node)%h)))
- prev;
/* Pointer to the next function in varpool_nodes_queue. */
struct varpool_node *
GTY ((nested_ptr (union symtab_node_def, (struct varpool_node *)(%h),
(symtab_node)%h)))
--- 415,424
/* The varpool data structure.
Each static variable decl has assigned varpool_node. */
! struct GTY(()) varpool_node {
struct symtab_node_base symbol;
/* For aliases points to declaration DECL is alias
Re: [C++ Patch] PR 49152
On Mon, Apr 16, 2012 at 8:31 AM, Paolo Carlini paolo.carl...@oracle.com wrote: Hi, On Mon, Apr 16, 2012 at 12:42 AM, Marc Glissemarc.gli...@inria.fr wrote: On Sun, 15 Apr 2012, Gabriel Dos Reis wrote: a hybrid approach; I would suggest something like this: (a) if caret is in effect, then print the caret pointing to the symbol in question; otherwise (b) print the symbol and the type (as suggested by Marc). I may have forgotten the details, but looking at the beginning of the PR, don't we always want the types? Yes. Ok, then do I understand correctly that we want something like the below? First, If the caret is not active, we print the reconstructed expression. Then always the types. I *think* things are fine translation-wise (I generated and inspected gcc.pot) and otherwise patch regtests fine on x86_64-linux (well, by default, when the caret is active, the behavior should be identical to what I posted about a month ago) Yes. Please document op_error_string. Patch OK with that.
Re: [Patch ARM] Fix PR51819.
Hi Uli, Apologies for the delayed response. Shouldn't the check be implemented along the following lines? if (memsize == 32 (align % 32) == 0) align_bits = 256; else if ((memsize == 16 || memsize == 32) (align % 16) == 0) align_bits = 128; else if (memsize = 8 (align % 8) == 0) align_bits = 64; else align_bits = 0; This looks OK to me. Looking at the ISA documents and the variants of the vldn instructions your summary is correct. The alignment specifier should not be greater than the memory size being transferred and checking this in this form is OK . regards, Ramana Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [patch optimization]: Add some basic folding for ==/!= comparison
2012/4/12 Richard Guenther richard.guent...@gmail.com:
On Thu, Apr 5, 2012 at 6:15 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch adds some basic folding capabilities to fold-const for
equal and none-equal comparisons
on integer typed argument.
ChangeLog
2012-04-05 Kai Tietz kti...@redhat.com
* fold-const.c (fold_comparison_1): New
function.
(fold_comparison): Use fold_comparison_1.
2012-04-05 Kai Tietz kti...@redhat.com
* gcc.dg/fold-compare-1.c: Adjust matching rule
for a == b without argument swap.
* gcc.dg/fold-compare-7.c: New test.
Regession tested for x86_64-unknown-linux-gnu for all languages
(including Ada and Obj-C++). Ok for apply?
Regards,
Kai
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -8739,6 +8739,241 @@ pointer_may_wrap_p (tree base, tree offs
return total_low (unsigned HOST_WIDE_INT) size;
}
+/* Sub-routine of fold_comparison. Folding of EQ_EXPR/NE_EXPR
+ comparisons with integral typed arguments. */
+
+static tree
+fold_comparison_1 (location_t loc, enum tree_code code, tree type,
+ tree arg0, tree arg1)
Please name it more specific, like for example
fold_integral_equality_comparison.
+{
+ enum tree_code c1, c2;
+ tree optype, op0, op1, opr0, opr1, tem;
+
+ if (code != NE_EXPR code != EQ_EXPR)
+ return NULL_TREE;
+
+ optype = TREE_TYPE (arg0);
+ if (!INTEGRAL_TYPE_P (optype))
+ return NULL_TREE;
+
+ c1 = TREE_CODE (arg0);
+ c2 = TREE_CODE (arg1);
+
+ /* Integer constant is on right-hand side. */
+ if (c1 == INTEGER_CST
+ c2 != c1)
+ return fold_build2_loc (loc, code, type, arg1, arg0);
/* If one arg is a real or integer constant, put it last. */
if (tree_swap_operands_p (arg0, arg1, true))
return fold_build2_loc (loc, swap_tree_comparison (code), type, op1, op0);
in fold_comparison already ensures this.
+ if (!TREE_SIDE_EFFECTS (arg0)
+ operand_equal_p (arg0, arg1, 0))
+ {
+ if (code == EQ_EXPR)
+ return build_one_cst (type);
+ return build_zero_cst (type);
+ }
This is already done in a more general way in fold_comparison:
Yes, was a duplicate like ...
/* Simplify comparison of something with itself. (For IEEE
floating-point, we can only do some of these simplifications.) */
if (operand_equal_p (arg0, arg1, 0))
{
switch (code)
{
case EQ_EXPR:
...
which also shows how to fold to true/false - using constant_boolean_node.
like this one. So I removed from patch.
+
+ if (c1 == NEGATE_EXPR)
+ {
+ op0 = TREE_OPERAND (arg0, 0);
+ /* -X ==/!= -Y - X ==/!= Y. */
+ if (c2 == c1)
+ return fold_build2_loc (loc, code, type,
+ op0,
+ TREE_OPERAND (arg1, 0));
This is already done, in a more general way but only for float types,
in fold_comparison. It's beyond me why it is conditional on float types
there and does not check for trapping math and NaNs (maybe that's
well-defined - one would need to double-check). For integral types
you'd have to care for undefined overflow (or issue a warning), and ...
You miss here explicit a point about ==/!= comparisons. The negate
can be removed for such comparisons uncoditionally, as there can't
happen an overflow, which changes result of compare. It would be even
a flaw for checking here for those cases about overflow.
+ /* -X ==/!= CST - X ==/!= CST' with CST'= -CST. */
+ else if (c2 == INTEGER_CST)
+ return fold_build2_loc (loc, code, type, op0,
+ fold_build1_loc (loc, NEGATE_EXPR,
+ optype, arg1));
... generalizing this the code should use negate_expr_p / negate_expr
to for example handle folding -b != b - a to b != a - b (of course you'd
require at least one explicit NEGATE_EXPR - similar foldings elsewhere
will tell you what to do).
See, above. No, it would be a failure to use negate_expr_p here, as
the overflow simply doesn't matter and there is also no need to warn
about it.
+ }
+ else if (c1 == BIT_NOT_EXPR)
+ {
+ op0 = TREE_OPERAND (arg0, 0);
+ /* ~X ==/!= ~Y - X ==/!= Y. */
+ if (c2 == c1)
+ return fold_build2_loc (loc, code, type, op0,
+ TREE_OPERAND (arg1, 0));
This can be generalized to relational comparisons as well I think. It's also
already done in fold_comparison here:
No it isn't. As again for ==/!= comparison the overflow simply
doesn't matter. Therefore I added this function to special-case
(non-)equal-comparison. The overflow cases are already handled for
general comparison, no need to do it twice.
/* Fold ~X op ~Y as Y op X. */
if (TREE_CODE (arg0) == BIT_NOT_EXPR
Re: [PATCH] Fix PR52977
On 4/16/12 10:43 AM, Richard Guenther wrote: Well, the number one advantage of replacing PCH is that it would kill the current PCH implementation which is tied to our garbage collector... Sure. That too. Diego.
Re: Use target_alias in validate_failures.py
On 4/16/12 7:32 AM, Rainer Orth wrote: Btw., it occured to me that it might be useful to add an option to locate out-of-tree manifests. I often have several source trees (unmodified sources, ones with local patches) and would like to share manifests between them. While this can be achieved with symlinks, a --manifest_dir or similar option might be an alternative. Thoughts? That would be fantastic. This is not the first time someone requests this, but I've never gotten around to implementing it. The only thing there is that multiple manifests means that versioning needs to be handled externally to the script. But that's not a big deal. 2012-04-15 Rainer Orthr...@cebitec.uni-bielefeld.de * testsuite-management/validate_failures.py (GetBuildData): Use target_alias. OK. Diego.
C++ PATCH for c++/51148 (missed error on unexpanded pack in friend declaration)
Just another place we need to call check_for_bare_parameter_packs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 616afbea9bf859633ade63b6536e5b63be5a19e6
Author: Jason Merrill ja...@redhat.com
Date: Mon Apr 16 09:23:41 2012 -0400
PR c++/51148
* friend.c (make_friend_class): Call check_for_bare_parameter_packs.
diff --git a/gcc/cp/friend.c b/gcc/cp/friend.c
index e532a30..87a093a 100644
--- a/gcc/cp/friend.c
+++ b/gcc/cp/friend.c
@@ -239,6 +239,9 @@ make_friend_class (tree type, tree friend_type, bool complain)
friend_type = cv_unqualified (friend_type);
+ if (check_for_bare_parameter_packs (friend_type))
+return;
+
if (friend_depth)
/* If the TYPE is a template then it makes sense for it to be
friends with itself; this means that each instantiation is
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic127.C b/gcc/testsuite/g++.dg/cpp0x/variadic127.C
new file mode 100644
index 000..2e0d593
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic127.C
@@ -0,0 +1,15 @@
+// PR c++/51148
+// { dg-do compile { target c++11 } }
+
+templatetypename... Types
+struct S
+{};
+
+templatetypename... Types
+struct T
+{
+ friend class STypes; // { dg-error parameter packs not expanded }
+};
+
+int main()
+{}
Re: [PATCH] Prevent 'control reaches end of non-void function' warning for DO_WHILE
On 04/14/2012 05:43 PM, Tom de Vries wrote: + tree expr = NULL; + append_to_statement_list (*block,expr); + *block = expr; Rather than doing this dance here, I think it would be better to enhance append_to_statement_list to handle the case of the list argument being a non-list. Added return value to append_to_statement_list, so now it's: *block = append_to_statement_list (*block, NULL); That's different from what I was suggesting; if the list argument is a pointer to a non-list, we can build up a list for at at that time, so we don't need the + *block = append_to_statement_list (*block, NULL); line at all; when we see + append_to_statement_list (build1 (LABEL_EXPR, void_type_node, label), + block); if *block isn't a STATEMENT_LIST we just make the necessary adjustments. Jason
[v3, testsuite] Fix merging default libstdc++.log
I've long noticed that libstdc++.log (unlike libstdc++.sum) doesn't contain log entries for tests run from abi.exp, but hadn't looked closer, getting used to check libstdc++.log.sep instead which contained everything I expected. This weekend, I've observed the same for the prettyprinters.exp failures reported in PR libstdc++/53006 and decided to investigate. It turns out that abi_check is the culprit: it emits its own summary in a style similar to what DejaGnu does: === libstdc++-v3 check-abi Summary === # of added symbols: 0 # of missing symbols:0 # of undesignated symbols: 0 # of incompatible symbols: 0 using: baseline_symbols.txt The header format is similar to what runtest emits, but the detail lines below are completely different. This is enought to seriously confuse contrib/dg-extract-results.sh -L badly enough to assume that this header line ends one variant, which otherwise only happens when doing multilib testing with intermediate summaries like === libstdc++ Summary for unix === # of expected passes50 === libstdc++ Summary for unix/-m64 === # of expected passes49 # of unexpected failures1 My (admittedly equally hacky solution) was to change the check-abi header format enough to avoid this confusion, and suddently the expected abi.exp and prettyprinters.exp log entries show up in the merged libstdc++.log as expected. Bootstrapped on i386-pc-solaris2.11, ok for mainline? Thanks. Rainer 2012-04-15 Rainer Orth r...@cebitec.uni-bielefeld.de * testsuite/util/testsuite_abi.cc (compare_symbols): Change summary header to avoid confision with DejaGnu header. # HG changeset patch # Parent 5fef8c66380e7570ac7c7a2b4b5aa94646c6bba4 Fix merging default libstdc++.log diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc b/libstdc++-v3/testsuite/util/testsuite_abi.cc --- a/libstdc++-v3/testsuite/util/testsuite_abi.cc +++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc @@ -530,7 +530,7 @@ compare_symbols(const char* baseline_fil } } - cout \n\t\t=== libstdc++-v3 check-abi Summary === endl; + cout \n\t\t libstdc++-v3 check-abi Summary endl; cout endl; cout # of added symbols:\t\t added_names.size() endl; cout # of missing symbols:\t\t missing_names.size() endl; -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH, i386, Android] Add Android support for i386 target
Hello, Here is patch for i386 Android support. It is the second part of previously splitted patch (http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00127.html). The first part has been committed (http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00378.html). Bootstrapped and checked on linux-x86_64. OK for trunk? Thanks, Ilya --- 2012-04-16 Enkovich Ilya ilya.enkov...@intel.com * config/i386/linux-common.h: New. * config.gcc: Add i386/linux-common.h before all i386/linux.h and i386/linux64.h usages. * config/i386/gnu-user.h (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. * config/i386/gnu-user64.h: Likewise. * config/i386/gnu-user.common.h (GNU_USER_TARGET_CC1_SPEC): New. (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. (GNU_USER_TARGET_MATHFILE_SPEC): New. (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. mandroid.patch Description: Binary data
Re: [PATCH, i386, Android] Add Android support for i386 target
On Mon, Apr 16, 2012 at 8:33 AM, Ilya Enkovich enkovich@gmail.com wrote: Hello, Here is patch for i386 Android support. It is the second part of previously splitted patch (http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00127.html). The first part has been committed (http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00378.html). Bootstrapped and checked on linux-x86_64. OK for trunk? Maybe it is better to break it into 2 patches: 1. Introduce config/i386/linux-common.h with any new functionalities 2. Add Android support. Thanks. H.J. --- Thanks, Ilya --- 2012-04-16 Enkovich Ilya ilya.enkov...@intel.com * config/i386/linux-common.h: New. * config.gcc: Add i386/linux-common.h before all i386/linux.h and i386/linux64.h usages. * config/i386/gnu-user.h (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. * config/i386/gnu-user64.h: Likewise. * config/i386/gnu-user.common.h (GNU_USER_TARGET_CC1_SPEC): New. (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. (GNU_USER_TARGET_MATHFILE_SPEC): New. (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC.
Re: [Patch ARM] Fix PR51819.
Ramana Radhakrishnan wrote: This looks OK to me. Looking at the ISA documents and the variants of the vldn instructions your summary is correct. The alignment specifier should not be greater than the memory size being transferred and checking this in this form is OK . Thanks, Ramana! I've checked in the following patch. Bye, Ulrich 2012-04-16 Ulrich Weigand ulrich.weig...@linaro.org * config/arm/arm.c (arm_print_operand): Fix invalid alignment hints for 'A' operand types. === modified file 'gcc/config/arm/arm.c' --- gcc/config/arm/arm.c2012-03-29 10:35:24 + +++ gcc/config/arm/arm.c2012-03-31 15:29:54 + @@ -17880,9 +17880,9 @@ memsize = MEM_SIZE (x); /* Only certain alignment specifiers are supported by the hardware. */ - if (memsize == 16 (align % 32) == 0) + if (memsize == 32 (align % 32) == 0) align_bits = 256; - else if (memsize == 16 (align % 16) == 0) + else if ((memsize == 16 || memsize == 32) (align % 16) == 0) align_bits = 128; else if (memsize = 8 (align % 8) == 0) align_bits = 64; -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [PATCH, i386, Android] Add Android support for i386 target
Maybe it is better to break it into 2 patches: 1. Introduce config/i386/linux-common.h with any new functionalities 2. Add Android support. Thanks. H.J. --- Hi, The first part will just add empty file. What is the reason to do it? Testing will not even reveal if I added it incorrectly. Thanks, Ilya
Re: [PATCH, i386, Android] Add Android support for i386 target
On Mon, Apr 16, 2012 at 9:01 AM, Ilya Enkovich enkovich@gmail.com wrote: Maybe it is better to break it into 2 patches: 1. Introduce config/i386/linux-common.h with any new functionalities 2. Add Android support. Thanks. H.J. --- Hi, The first part will just add empty file. What is the reason to do it? Testing will not even reveal if I added it incorrectly. It should contain everything, minus any new Android changes, which should be in the second patch. It has nothing but defines for Android. It did not move any existing code to this file. Ilya -- H.J.
Symbol table 6/many: Symbol table hashes
Hi,
this patch moves cgraph/varpool hashes into symbol table hashes, so the
symbol table is actually almost a symbol table ;)
Work done.
Bootstrapped/regtested x86_64-linux. Will commit it after bit of more
testing - the assembler name handling is slipperly wrt aliases.
Honza
* cgraph.c (cgraph_hash, assembler_name_hash): Remove.
(hash_node, eq_node): Remove.
(cgraph_create_node): Do not handle hashtable.
(cgraph_get_node): Remove.
(cgraph_insert_node_to_hashtable): Remove.
(hash_node_by_assembler_name): Remove.
(eq_assembler_name): Remove.
(cgraph_node_for_asm): Rewrite.
(cgraph_find_replacement_node): Break out from ...
(cgraph_remove_node): ... here; do not maintain hashtables.
(change_decl_assembler_name): Remove.
(cgraph_clone_node): Do not maintain hashtables.
* cgraph.h (const_symtab_node): New typedef.
(cgraph_insert_node_to_hashtable): Remove.
(symtab_get_node, symtab_node_for_asm,
symtab_insert_node_to_hashtable): Declare.
(cgraph_find_replacement_node): Declare.
(cgraph_get_node, varpool_get_node): Turn into inlines.
(cgraph, varpool): Work sanely on NULL pointers.
(FOR_EACH_SYMBOL): New walker.
* ipa-inline-transform.c (save_inline_function_body): Use
symtab_insert_node_to_hashtable.
* symtab.c: Include ggc.h and diagnostics.h
(symtab_hash, assembler_name_hash): New static vars;
(hash_node, eq_node, hash_node_by_assembler_name,
eq_assembler_name): New.
(symtab_register_node): Update hashtables.
(symtab_insert_node_to_hashtable): New.
(symtab_unregister_node): Update hashtables.
(symtab_get_node): New.
(symtab_node_for_asm): New.
(change_decl_assembler_name): New.
* Makefile.in (symtab.o): Needs GTY.
* varpool.c (varpool_hash): Remove.
(hash_varpool_node, eq_varpool_node, varpool_get_node): Remove.
(varpool_node): Rewrite using varpool_get_node.
(varpool_remove_node): DO not maintain hashtables.
(varpool_node_for_asm); Rewrite.
Index: cgraph.c
===
*** cgraph.c(revision 186496)
--- cgraph.c(working copy)
*** static void cgraph_node_remove_callers (
*** 119,129
static inline void cgraph_edge_remove_caller (struct cgraph_edge *e);
static inline void cgraph_edge_remove_callee (struct cgraph_edge *e);
- /* Hash table used to convert declarations into nodes. */
- static GTY((param_is (union symtab_node_def))) htab_t cgraph_hash;
- /* Hash table used to convert assembler names into nodes. */
- static GTY((param_is (union symtab_node_def))) htab_t assembler_name_hash;
-
/* Queue of cgraph nodes scheduled to be lowered. */
symtab_node x_cgraph_nodes_queue;
#define cgraph_nodes_queue ((struct cgraph_node *)x_cgraph_nodes_queue)
--- 119,124
*** cgraph_call_node_duplication_hooks (stru
*** 419,444
}
}
- /* Returns a hash code for P. */
-
- static hashval_t
- hash_node (const void *p)
- {
- const struct cgraph_node *n = (const struct cgraph_node *) p;
- return (hashval_t) DECL_UID (n-symbol.decl);
- }
-
-
- /* Returns nonzero if P1 and P2 are equal. */
-
- static int
- eq_node (const void *p1, const void *p2)
- {
- const struct cgraph_node *n1 = (const struct cgraph_node *) p1;
- const struct cgraph_node *n2 = (const struct cgraph_node *) p2;
- return DECL_UID (n1-symbol.decl) == DECL_UID (n2-symbol.decl);
- }
-
/* Allocate new callgraph node. */
static inline struct cgraph_node *
--- 414,419
*** cgraph_create_node_1 (void)
*** 479,520
struct cgraph_node *
cgraph_create_node (tree decl)
{
! struct cgraph_node key, *node, **slot;
!
gcc_assert (TREE_CODE (decl) == FUNCTION_DECL);
- if (!cgraph_hash)
- cgraph_hash = htab_create_ggc (10, hash_node, eq_node, NULL);
-
- key.symbol.decl = decl;
- slot = (struct cgraph_node **) htab_find_slot (cgraph_hash, key, INSERT);
- gcc_assert (!*slot);
-
- node = cgraph_create_node_1 ();
node-symbol.decl = decl;
! symtab_register_node ((symtab_node)node);
! *slot = node;
if (DECL_CONTEXT (decl) TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL)
{
node-origin = cgraph_get_create_node (DECL_CONTEXT (decl));
node-next_nested = node-origin-nested;
node-origin-nested = node;
}
- if (assembler_name_hash)
- {
- void **aslot;
- tree name = DECL_ASSEMBLER_NAME (decl);
-
- aslot = htab_find_slot_with_hash (assembler_name_hash, name,
- decl_assembler_name_hash (name),
- INSERT);
- /* We can have multiple declarations with same assembler name. For C++
-it is __builtin_strlen and strlen, for instance. Do we need
Re: [PATCH, i386, Android] Add Android support for i386 target
On Mon, Apr 16, 2012 at 9:08 AM, Ilya Enkovich enkovich@gmail.com wrote: On Mon, Apr 16, 2012 at 9:01 AM, Ilya Enkovich enkovich@gmail.com wrote: Maybe it is better to break it into 2 patches: 1. Introduce config/i386/linux-common.h with any new functionalities 2. Add Android support. Thanks. H.J. --- Hi, The first part will just add empty file. What is the reason to do it? Testing will not even reveal if I added it incorrectly. It should contain everything, minus any new Android changes, which should be in the second patch. It has nothing but defines for Android. It did not move any existing code to this file. Adding linux-common.h to i386 backend needs approval from i386 backend maintainer. If a patch also adds Android support, i386 backend maintainer may not feel comfortable to review it. However, if you simplify add linux-common.h with XXX_SPEC, i386 backend maintainer can review it easily. -- H.J.
Re: RFA: always supply a mode to plus_constant
On 04/15/2012 02:29 AM, Richard Sandiford wrote: alpha-linux-gnu arm-linux-gnueabi avr-rtems bfin-elf c6x-elf cr16-elf cris-elf epiphany-elf fr30-elf frv-linux-gnu h8300-elf ia64-linux-gnu iq2000-elf lm32-elf m32c-elf m32r-elf m68k-linux-gnu mcore-elf mep-elf microblaze-elf mips-linux-gnu mmix mn10300-elf moxie-elf hppa64-hp-hpux11.23 pdp11 picochip-elf powerpc-linux-gnu powerpc-eabispe rl78-elf rx-elf s390-linux-gnu score-elf sh-linux-gnu sparc-linux-gnu spu-elf tilegx-elf tilepro-elf xstormy16-elf v850-elf vax-netbsdelf xtensa-elf OK to install? * config/microblaze/microblaze.c (double_memory_operand) (microblaze_block_move_loop): Likewise. OK. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Fortran] Patch ping
Hi Tobias, - [patch, fortran] Trim spaces on list-directed reads http://gcc.gnu.org/ml/fortran/2012-04/msg00040.html That one was committed: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00417.html Jerry indicated that this would also be OK for a backport; I'll do that within a few days unless there are objections. - [patch, fortran-dev] Use fixed variable sizes for stride calculations http://gcc.gnu.org/ml/fortran/2012-04/msg00074.html That one is http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00400.html A more general question: I habe been a bit inconsistent in notifying the mailing list about committed patches; I didn't do this for these patches. What would people, generally, prefer? Should we notify on commit, or rather not? Regards Thomas
Re: [PATCH] Fix PR52977
On Mon, Apr 16, 2012 at 3:38 PM, Diego Novillo dnovi...@google.com wrote: I'm not sure PPH will replace PCH - will it? In theory, it may. But it's not in the immediate plans. IMHO, the case for including PPH would be much stronger if replacing PCH would be included in the immediate to mid-term plans. The current implementation of PCH has so many disadvantages, both for GCC internals and for users, that it is hardly useful. It seems to have been developed with one particular use in mind: projects with OHRTA (One Header to Rule Them All), like Apple's Objective-C library framework. To get an idea of how widely used PCH is, I looked at bugzilla. GCC has had PCH since GCC 3.4, which is almost 8 years old (18 April 2004). In that time, 93 bugs about PCH have been filed in Bugzilla, of which 17 were duplicates, and 13 were invalid (including 3 WORKSFORME). 26 bugs remain open (only two have been assigned to someone to fix, with no action since forever). So either PCH is remarkably bug-free, or hardly anyone is actually using it. (For comparison, 3256 c++ bugs were filed since GCC 3.4, with 414 duplicates, 488 invalid, and 521 remaining open.) Distributors obviously have better sources of data to measure how useful PCH is, and I'd be curious to know e.g. how many packages in Fedora or openSuSE use PCH... The big thing that PCH has going for it is load speed. PCH is almost instantaneous, PPH isn't. A 1Gb PCH file can be restored in 1s, the corresponding PPH file needs ~8s to restore. The implementation can still be tuned for performance, but it will never be as fast as a couple of mmap operations. I think it is not reasonable to compare PCH to PPH like that. Perhaps that 8s is still only a small amount of time for the whole compilation process, and still only a fraction of the time for lexing+parsing the underlying source code. PPH is a much smaller representation (that 1Gb PCH file can be represented in 400Mb in PPH) and more flexible (almost any arbitrary subset of headers can be turned into separate PPH images). Another advantage would be that PPHs can be made practically machine-indepenent (GCC is not quite ready for it, but at least in theory this could be done with PPHs but not with a PCH). Others have already compared the GCC PCH and PTH/PPH approaches, so for some arguments against GCC's existing PCH implementation and some arguments for PPH/PTH see: http://clang.llvm.org/docs/PTHInternals.html http://gcc.gnu.org/wiki/PCHHaters So, it's not clear whether we will want to replace PCH with PPH. Flexibility costs raw performance. If the performance gap can be bridged, we may want to consider it in the future. I think the other advantages and disadvantages, apart from performance, should also be considered in such a decision. Ciao! Steven
Re: [patch optimization]: Add some basic folding for ==/!= comparison
On Mon, Apr 16, 2012 at 3:58 PM, Kai Tietz ktiet...@googlemail.com wrote:
2012/4/12 Richard Guenther richard.guent...@gmail.com:
On Thu, Apr 5, 2012 at 6:15 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch adds some basic folding capabilities to fold-const for
equal and none-equal comparisons
on integer typed argument.
ChangeLog
2012-04-05 Kai Tietz kti...@redhat.com
* fold-const.c (fold_comparison_1): New
function.
(fold_comparison): Use fold_comparison_1.
2012-04-05 Kai Tietz kti...@redhat.com
* gcc.dg/fold-compare-1.c: Adjust matching rule
for a == b without argument swap.
* gcc.dg/fold-compare-7.c: New test.
Regession tested for x86_64-unknown-linux-gnu for all languages
(including Ada and Obj-C++). Ok for apply?
Regards,
Kai
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -8739,6 +8739,241 @@ pointer_may_wrap_p (tree base, tree offs
return total_low (unsigned HOST_WIDE_INT) size;
}
+/* Sub-routine of fold_comparison. Folding of EQ_EXPR/NE_EXPR
+ comparisons with integral typed arguments. */
+
+static tree
+fold_comparison_1 (location_t loc, enum tree_code code, tree type,
+ tree arg0, tree arg1)
Please name it more specific, like for example
fold_integral_equality_comparison.
+{
+ enum tree_code c1, c2;
+ tree optype, op0, op1, opr0, opr1, tem;
+
+ if (code != NE_EXPR code != EQ_EXPR)
+ return NULL_TREE;
+
+ optype = TREE_TYPE (arg0);
+ if (!INTEGRAL_TYPE_P (optype))
+ return NULL_TREE;
+
+ c1 = TREE_CODE (arg0);
+ c2 = TREE_CODE (arg1);
+
+ /* Integer constant is on right-hand side. */
+ if (c1 == INTEGER_CST
+ c2 != c1)
+ return fold_build2_loc (loc, code, type, arg1, arg0);
/* If one arg is a real or integer constant, put it last. */
if (tree_swap_operands_p (arg0, arg1, true))
return fold_build2_loc (loc, swap_tree_comparison (code), type, op1, op0);
in fold_comparison already ensures this.
+ if (!TREE_SIDE_EFFECTS (arg0)
+ operand_equal_p (arg0, arg1, 0))
+ {
+ if (code == EQ_EXPR)
+ return build_one_cst (type);
+ return build_zero_cst (type);
+ }
This is already done in a more general way in fold_comparison:
Yes, was a duplicate like ...
/* Simplify comparison of something with itself. (For IEEE
floating-point, we can only do some of these simplifications.) */
if (operand_equal_p (arg0, arg1, 0))
{
switch (code)
{
case EQ_EXPR:
...
which also shows how to fold to true/false - using constant_boolean_node.
like this one. So I removed from patch.
+
+ if (c1 == NEGATE_EXPR)
+ {
+ op0 = TREE_OPERAND (arg0, 0);
+ /* -X ==/!= -Y - X ==/!= Y. */
+ if (c2 == c1)
+ return fold_build2_loc (loc, code, type,
+ op0,
+ TREE_OPERAND (arg1, 0));
This is already done, in a more general way but only for float types,
in fold_comparison. It's beyond me why it is conditional on float types
there and does not check for trapping math and NaNs (maybe that's
well-defined - one would need to double-check). For integral types
you'd have to care for undefined overflow (or issue a warning), and ...
You miss here explicit a point about ==/!= comparisons. The negate
can be removed for such comparisons uncoditionally, as there can't
happen an overflow, which changes result of compare. It would be even
a flaw for checking here for those cases about overflow.
You miss the fact that the _negate_ can overflow. Thus, with -ftrapv
you can end up removing a side-effect.
+ /* -X ==/!= CST - X ==/!= CST' with CST'= -CST. */
+ else if (c2 == INTEGER_CST)
+ return fold_build2_loc (loc, code, type, op0,
+ fold_build1_loc (loc, NEGATE_EXPR,
+ optype, arg1));
... generalizing this the code should use negate_expr_p / negate_expr
to for example handle folding -b != b - a to b != a - b (of course you'd
require at least one explicit NEGATE_EXPR - similar foldings elsewhere
will tell you what to do).
See, above. No, it would be a failure to use negate_expr_p here, as
the overflow simply doesn't matter and there is also no need to warn
about it.
negate_expr_p is not about overflow but about can we cheaply negate this?
Thus, if you have -X == Y and negate_expr_p returns true for Y you can
fold it to X == negate_expr (Y). No need to only handle integer constants.
+ }
+ else if (c1 == BIT_NOT_EXPR)
+ {
+ op0 = TREE_OPERAND (arg0, 0);
+ /* ~X ==/!= ~Y - X ==/!= Y. */
+ if (c2 == c1)
+ return fold_build2_loc (loc, code, type, op0,
+ TREE_OPERAND (arg1, 0));
This can be generalized to
Re: [testsuite] Fix plugin testsuite, remove uses of TODO_dump_func (PR testsuite/52948)
cc Richard. thanks, David On Mon, Apr 16, 2012 at 3:24 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: As reported in PR testsuite/52948, several plugin testcases were failing since the removal of TODO_dump_func: UNRESOLVED: selfassign.c compilation, -I. -I/vol/gcc/src/hg/trunk/local/gcc/testsuite -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../gcc -I/var/gcc/regression/trunk/11-gcc/build/gcc/testsuite/g++/../../../gcc -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../include -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/../../libcpp/include -I/vol/gcc/include -I/vol/gcc/include -I/vol/gcc/include -I/var/gcc/regression/trunk/11-gcc/build/gcc/testsuite/g++/../../../intl -O -DIN_GCC -fPIC -shared I have no idea why this has been missed when testing the removal patch, because the failures are very prominent in mail-report.log (maybe because the incorrectly show up as UNRESOLVED instead of FAIL). This patch fixes this by removing the uses of TODO_dump_func from the affected plugins. At the same time, I'm finally fixing some issues with the plugin tests that have annoyed me for quite some time: * The tests should log the full (relative) path to the testcase, not only the basenames. * Using unresolved to report failures to compile the plugins is wrong: this should be fail instead, and the pass case needs to be logged as well. * There's no point in logging the options used to compile the plugin: they are completely internal to plugin-support.exp and not in any way influenced by the testsuite drivers. There's one issue I didn't fix due to the large number of (bad) precedents in the testsuite: * If a plugin fails to compile, the compilations using it should become unresolved instead of just returning early. Bootstrapped without regressions on i386-pc-solaris2.11, installed on mainline. Rainer 2012-04-14 Rainer Orth r...@cebitec.uni-bielefeld.de gcc/testsuite: * lib/plugin-support.exp (plugin-test-execute): Properly determine testcase name. Use fail, pass instead of unresolved. Don't log $optstr. PR testsuite/52948 * g++.dg/plugin/dumb_plugin.c (pass_dumb_plugin_example): Remove TODO_dump_func. * g++.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise. * gcc.dg/plugin/one_time_plugin.c (one_pass): Likewise. * gcc.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise. -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch optimization]: Add some basic folding for ==/!= comparison
2012/4/16 Richard Guenther richard.guent...@gmail.com:
On Mon, Apr 16, 2012 at 3:58 PM, Kai Tietz ktiet...@googlemail.com wrote:
2012/4/12 Richard Guenther richard.guent...@gmail.com:
On Thu, Apr 5, 2012 at 6:15 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch adds some basic folding capabilities to fold-const for
equal and none-equal comparisons
on integer typed argument.
ChangeLog
2012-04-05 Kai Tietz kti...@redhat.com
* fold-const.c (fold_comparison_1): New
function.
(fold_comparison): Use fold_comparison_1.
2012-04-05 Kai Tietz kti...@redhat.com
* gcc.dg/fold-compare-1.c: Adjust matching rule
for a == b without argument swap.
* gcc.dg/fold-compare-7.c: New test.
Regession tested for x86_64-unknown-linux-gnu for all languages
(including Ada and Obj-C++). Ok for apply?
Regards,
Kai
Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -8739,6 +8739,241 @@ pointer_may_wrap_p (tree base, tree offs
return total_low (unsigned HOST_WIDE_INT) size;
}
+/* Sub-routine of fold_comparison. Folding of EQ_EXPR/NE_EXPR
+ comparisons with integral typed arguments. */
+
+static tree
+fold_comparison_1 (location_t loc, enum tree_code code, tree type,
+ tree arg0, tree arg1)
Please name it more specific, like for example
fold_integral_equality_comparison.
+{
+ enum tree_code c1, c2;
+ tree optype, op0, op1, opr0, opr1, tem;
+
+ if (code != NE_EXPR code != EQ_EXPR)
+ return NULL_TREE;
+
+ optype = TREE_TYPE (arg0);
+ if (!INTEGRAL_TYPE_P (optype))
+ return NULL_TREE;
+
+ c1 = TREE_CODE (arg0);
+ c2 = TREE_CODE (arg1);
+
+ /* Integer constant is on right-hand side. */
+ if (c1 == INTEGER_CST
+ c2 != c1)
+ return fold_build2_loc (loc, code, type, arg1, arg0);
/* If one arg is a real or integer constant, put it last. */
if (tree_swap_operands_p (arg0, arg1, true))
return fold_build2_loc (loc, swap_tree_comparison (code), type, op1,
op0);
in fold_comparison already ensures this.
+ if (!TREE_SIDE_EFFECTS (arg0)
+ operand_equal_p (arg0, arg1, 0))
+ {
+ if (code == EQ_EXPR)
+ return build_one_cst (type);
+ return build_zero_cst (type);
+ }
This is already done in a more general way in fold_comparison:
Yes, was a duplicate like ...
/* Simplify comparison of something with itself. (For IEEE
floating-point, we can only do some of these simplifications.) */
if (operand_equal_p (arg0, arg1, 0))
{
switch (code)
{
case EQ_EXPR:
...
which also shows how to fold to true/false - using constant_boolean_node.
like this one. So I removed from patch.
+
+ if (c1 == NEGATE_EXPR)
+ {
+ op0 = TREE_OPERAND (arg0, 0);
+ /* -X ==/!= -Y - X ==/!= Y. */
+ if (c2 == c1)
+ return fold_build2_loc (loc, code, type,
+ op0,
+ TREE_OPERAND (arg1, 0));
This is already done, in a more general way but only for float types,
in fold_comparison. It's beyond me why it is conditional on float types
there and does not check for trapping math and NaNs (maybe that's
well-defined - one would need to double-check). For integral types
you'd have to care for undefined overflow (or issue a warning), and ...
You miss here explicit a point about ==/!= comparisons. The negate
can be removed for such comparisons uncoditionally, as there can't
happen an overflow, which changes result of compare. It would be even
a flaw for checking here for those cases about overflow.
You miss the fact that the _negate_ can overflow. Thus, with -ftrapv
you can end up removing a side-effect.
+ /* -X ==/!= CST - X ==/!= CST' with CST'= -CST. */
+ else if (c2 == INTEGER_CST)
+ return fold_build2_loc (loc, code, type, op0,
+ fold_build1_loc (loc, NEGATE_EXPR,
+ optype, arg1));
... generalizing this the code should use negate_expr_p / negate_expr
to for example handle folding -b != b - a to b != a - b (of course you'd
require at least one explicit NEGATE_EXPR - similar foldings elsewhere
will tell you what to do).
See, above. No, it would be a failure to use negate_expr_p here, as
the overflow simply doesn't matter and there is also no need to warn
about it.
negate_expr_p is not about overflow but about can we cheaply negate this?
Thus, if you have -X == Y and negate_expr_p returns true for Y you can
fold it to X == negate_expr (Y). No need to only handle integer constants.
Hmm, can't confirm that. Neither by code, nor by its comment:
/* Determine whether an expression T can be cheaply negated using
the function negate_expr without introducing undefined overflow. */
static bool
negate_expr_p
Re: PING: PATCH: Backport x32 support to libtool
On Tue, Apr 3, 2012 at 7:49 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Mar 29, 2012 at 7:34 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Mar 3, 2012 at 9:54 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
This patch backports x32 support to libtool:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=88992fe6771ec3258bde1b03314ce579da0ac2d5
OK to install?
Thanks.
H.J.
---
ommit 0d8c092cac25c3bce5dbfc1981b84df91b3f6086
Author: H.J. Lu hjl.to...@gmail.com
Date: Mon Dec 12 13:03:14 2011 -0800
Add x32 support to libtool.m4
2011-12-12 H.J. Lu hongjiu...@intel.com
* libtool.m4 (_LT_ENABLE_LOCK): Support x32.
diff --git a/ChangeLog.x32 b/ChangeLog.x32
new file mode 100644
index 000..b6e01ee
--- /dev/null
+++ b/ChangeLog.x32
@@ -0,0 +1,3 @@
+2011-12-12 H.J. Lu hongjiu...@intel.com
+
+ * libtool.m4 (_LT_ENABLE_LOCK): Support x32.
diff --git a/libtool.m4 b/libtool.m4
index 67321a7..a7f99ac 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -1232,7 +1232,14 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
LD=${LD-ld} -m elf_i386_fbsd
;;
x86_64-*linux*)
- LD=${LD-ld} -m elf_i386
+ case `/usr/bin/file conftest.o` in
+ *x86-64*)
+ LD=${LD-ld} -m elf32_x86_64
+ ;;
+ *)
+ LD=${LD-ld} -m elf_i386
+ ;;
+ esac
;;
ppc64-*linux*|powerpc64-*linux*)
LD=${LD-ld} -m elf32ppclinux
Hi Ralf,
Can you review this patch?
Thanks.
PING.
PING.
--
H.J.
Re: [v3, testsuite] Fix merging default libstdc++.log
On Apr 16, 2012, at 8:03 AM, Rainer Orth wrote: I've long noticed that libstdc++.log (unlike libstdc++.sum) doesn't contain log entries for tests run from abi.exp, but hadn't looked closer, getting used to check libstdc++.log.sep instead which contained everything I expected. ok for mainline? Ok. Would have been nice to see the before and after log file...
Re: RFC reminder: an alternative -fsched-pressure implementation
On 04/10/2012 09:35 AM, Richard Sandiford wrote: Hi Vlad, Back in Decemember, when we were still very much in stage 3, I sent an RFC about an alternative implementation of -fsched-pressure. Just wanted to send a reminder now that we're in the proper stage: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01684.html Ulrich has benchmarked it on ARM, S/390 and Power7 (thanks), and got reasonable results. (I mentioned bad Power 7 results in that message, because of the way the VSX_REGS class is handled. Ulrich's results are without -mvsx though.) The condition I orignally set myself was that this patch should only go in if it becomes the default on at least one architecture, specifically ARM. Ulrich tells me that Linaro have now made it the default for ARM in their GCC 4.7 release, so hopefully Ramana would be OK with doing the same in upstream 4.8. I realise the whole thing is probably more complicated and ad-hoc than you'd like. Saying it can't go in is a perfectly acceptable answer IMO. I have a mixed feeling with the patch. I've tried it on SPEC2000 on x86/x86-64 and ARM. Model algorithm generates bigger code up to 3.5% (SPECFP on x86), 2% (SPECFP on 86-64), and 0.23% (SPECFP on ARM) in comparison with the current algorithm. It is slower too. Although the difference is quite insignificant on Corei7, compiler speed slowdown achieves 0.4% on SPECFP2000 on arm. The algorithm also generates slower code on x86 (1.5% on SPECINT and 5% on SPECFP200) and practically the same average code on x86-64 and ARM (I've tried only SPECINT on ARM). On the other hand, I don't think that 1st insn scheduling will be ever used for x86. And although the SPECFP2000 rate is the same on x86-64 I saw that some SPECFP2000 tests benefit from your algorithm on x86-64 (one amazing difference is 70% improvement on swim on x86-64 although it might be because of different reasons like alignment or cache behaviour). So I think the algorithm might work better on processors with more registers. I gues it is ok to sumbit this work to the trunk. It may be useful for achieving better performance for specific tests or to make it a default for some targets if it is proven to be better. As for the patch itself, I think you should document the option in doc/invoke.texi. It is missed. Another minor mistake I found is one line garbage (I guess from -fira-algorithm) in description of -fsched-pressure-algorithm in common.opt. Thanks, Richard. By the way, the code in scheduler has been changed since you made a patch and you need to do some merging first.
[Patch,AVR]: Auto-generate all -mmcu= options in documentation.
This patch adds a new file ./gcc/doc/avr-mmcu.texi that lists all valid
-mmcu= settings and replaces the respective text in invoke.texi by
@include avr-mmcu.texi
Up to now, there is no complete list of -mmcu= options, and a list is
hard to maintain by hand because it contains more than 180 devices.
If, during the build of avr-gcc, a change of ./gcc/doc/avr-mmcu.texi
is detected, the build aborts with a message that nags the user to
copy the new content of avr-mmcu.texi to ./gcc/doc/avr-mmcu.texi.
The error message's text is:
*** Verify that you have permission to grant a
*** GFDL license for all new text in
*** avr-mmcu.texi, then copy it to $(srcdir)/doc/avr-mmcu.texi
./gcc/doc/avr-mmcu.texi is auto-generated, but there is no rule to
automatically update it during the build process.
Documents (HTML, PDF, ...) build fine.
Ok for trunk?
If it's appropriate for 4.7, I'd change invoke.texi accordingly by
copy-pasting the auto-generated texi code into that file, i.e.
into section AVR Options.
Johann
* Makefile.in (TEXI_GCC_FILES): Add avr-mmcu.texi.
* doc/avr-mmcu.texi: New auto-generated file.
* doc/invoke.texi (AVR Options): Include avr-mmcu.texi in order
to document all valid -mmcu= arguments.
* config/avr/avr.h (arch_info_s): New struct definition.
* config/avr/avr-devices.c (avr_texinfo): New variable.
* config/avr/gen-avr-mmcu-texi.c: New file.
* config/avr/t-avr: New rules and dependencies to build avr-mmcu.texi.
Index: doc/avr-mmcu.texi
===
--- doc/avr-mmcu.texi (revision 0)
+++ doc/avr-mmcu.texi (revision 0)
@@ -0,0 +1,74 @@
+@c Copyright (C) 2012 Free Software Foundation, Inc.
+@c This is part of the GCC manual.
+@c For copying conditions, see the file gcc/doc/include/fdl.texi.
+
+@c This file is generated automatically using
+@c gcc/config/avr/gen-avr-mmcu-texi.c from:
+@cgcc/config/avr/avr-devices.c
+@cgcc/config/avr/avr-mcus.def
+
+@c Please do not edit manually.
+
+@table @code
+
+@item avr2
+``Classic'' devices with up to 8@tie{}KiB of program memory.
+@*@var{mcu}@tie{}= @code{at90s2313}, @code{at90s2323}, @code{at90s2333}, @code{at90s2343}, @code{attiny22}, @code{attiny26}, @code{at90s4414}, @code{at90s4433}, @code{at90s4434}, @code{at90s8515}, @code{at90c8534}, @code{at90s8535}.
+
+@item avr25
+``Classic'' devices with up to 8@tie{}KiB of program memory and with the @code{MOVW} instruction.
+@*@var{mcu}@tie{}= @code{ata6289}, @code{attiny13}, @code{attiny13a}, @code{attiny2313}, @code{attiny2313a}, @code{attiny24}, @code{attiny24a}, @code{attiny4313}, @code{attiny44}, @code{attiny44a}, @code{attiny84}, @code{attiny84a}, @code{attiny25}, @code{attiny45}, @code{attiny85}, @code{attiny261}, @code{attiny261a}, @code{attiny461}, @code{attiny461a}, @code{attiny861}, @code{attiny861a}, @code{attiny43u}, @code{attiny87}, @code{attiny48}, @code{attiny88}, @code{at86rf401}.
+
+@item avr3
+``Classic'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
+@*@var{mcu}@tie{}= @code{at43usb355}, @code{at76c711}.
+
+@item avr31
+``Classic'' devices with 128@tie{}KiB of program memory.
+@*@var{mcu}@tie{}= @code{atmega103}, @code{at43usb320}.
+
+@item avr35
+``Classic'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory and with the @code{MOVW} instruction.
+@*@var{mcu}@tie{}= @code{at90usb82}, @code{at90usb162}, @code{atmega8u2}, @code{atmega16u2}, @code{atmega32u2}, @code{attiny167}.
+
+@item avr4
+``Enhanced'' devices with up to 8@tie{}KiB of program memory.
+@*@var{mcu}@tie{}= @code{atmega8}, @code{atmega48}, @code{atmega48a}, @code{atmega48p}, @code{atmega88}, @code{atmega88a}, @code{atmega88p}, @code{atmega88pa}, @code{atmega8515}, @code{atmega8535}, @code{atmega8hva}, @code{at90pwm1}, @code{at90pwm2}, @code{at90pwm2b}, @code{at90pwm3}, @code{at90pwm3b}, @code{at90pwm81}.
+
+@item avr5
+``Enhanced'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
+@*@var{mcu}@tie{}= @code{atmega16}, @code{atmega16a}, @code{atmega161}, @code{atmega162}, @code{atmega163}, @code{atmega164a}, @code{atmega164p}, @code{atmega165}, @code{atmega165a}, @code{atmega165p}, @code{atmega168}, @code{atmega168a}, @code{atmega168p}, @code{atmega169}, @code{atmega169a}, @code{atmega169p}, @code{atmega169pa}, @code{atmega32}, @code{atmega323}, @code{atmega324a}, @code{atmega324p}, @code{atmega324pa}, @code{atmega325}, @code{atmega325a}, @code{atmega325p}, @code{atmega3250}, @code{atmega3250a}, @code{atmega3250p}, @code{atmega328}, @code{atmega328p}, @code{atmega329}, @code{atmega329a}, @code{atmega329p}, @code{atmega329pa}, @code{atmega3290}, @code{atmega3290a}, @code{atmega3290p}, @code{atmega406}, @code{atmega64}, @code{atmega640}, @code{atmega644}, @code{atmega644a}, @code{atmega644p}, @code{atmega644pa}, @code{atmega645}, @code{atmega645a}, @code{atmega645p}, @code{atmega6450}, @code{atmega6450a}, @code{atmega6450p}, @code{atmega649}, @code{atmega649a},
[PATCH] arm.md: Use the revsh and rev16 instructions for BSWAP:HI RTL in armv6 and up
This patch teaches the arm target about the rev16 and revsh
instructions which can
efficiently execute the recently added __builtin_bswap16() function
(BSWAP:HI in RTL)
These instructions are available in thumb and arm modes on armv6
architecture and up.
Before this patch,
short swaps16(short x) {
return __builtin_bswap16(x);
}
unsigned short swapu16(unsigned short x) {
return __builtin_bswap16(x);
}
$ gcc -S -dp -O2 -marm -march=armv6 test_bswap16.c
outputs:
swaps16:
uxthr3, r0 @ 8 *arm_zero_extendhisi2_v6/1 [length = 4]
mov r3, r3, lsr #8 @ 9 *arm_shiftsi3 [length = 4]
orr r0, r3, r0, asl #8 @ 12*arith_shiftsi/1
[length = 4]
sxthr0, r0 @ 19*arm_extendhisi2_v6/1 [length = 4]
bx lr @ 29*arm_return [length = 12]
swapu16:
mov r3, r0, lsr #8 @ 7 *arm_shiftsi3 [length = 4]
orr r0, r3, r0, asl #8 @ 10*arith_shiftsi/1
[length = 4]
uxthr0, r0 @ 16*arm_zero_extendhisi2_v6/1 [length = 4]
bx lr @ 26*arm_return [length = 12]
After this patch it produces:
swaps16:
revsh r0, r0 @ 13*arm_revsh [length = 4]
bx lr @ 23*arm_return [length = 12]
swapu16:
rev16 r0, r0 @ 6 *arm_rev16 [length = 4]
uxthr0, r0 @ 12*arm_zero_extendhisi2_v6/1 [length = 4]
bx lr @ 22*arm_return [length = 12]
Similar improvements are seen for -mthumb -march=armv6 and -mthumb
-march=armv6t2
--- ChangeLog ---
2012-04-16 Louis Kruger lou...@gmail.com
* arm.md: Use the revsh and rev16 instructions for BSWAP:HI
RTL in armv6 and up
---
gcc/config/arm/arm.md | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 79eff0e..317e295 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -11327,6 +11327,24 @@
(set_attr length 4)]
)
+(define_insn *arm_revsh
+ [(set (match_operand:SI 0 s_register_operand =r)
+ (sign_extend:SI (bswap:HI (match_operand:HI 1 s_register_operand
r]
+ TARGET_32BIT arm_arch6
+ revsh%?\t%0, %1
+ [(set_attr predicable yes)
+ (set_attr length 4)]
+)
+
+(define_insn *arm_rev16
+ [(set (match_operand:HI 0 s_register_operand =r)
+ (bswap:HI (match_operand:HI 1 s_register_operand r)))]
+ TARGET_32BIT arm_arch6
+ rev16%?\t%0, %1
+ [(set_attr predicable yes)
+ (set_attr length 4)]
+)
+
(define_insn *thumb1_rev
[(set (match_operand:SI 0 s_register_operand =l)
(bswap:SI (match_operand:SI 1 s_register_operand l)))]
@@ -11335,6 +11353,22 @@
[(set_attr length 2)]
)
+(define_insn *thumb1_revsh
+ [(set (match_operand:SI 0 s_register_operand =l)
+ (sign_extend:SI (bswap:HI (match_operand:HI 1 s_register_operand
l]
+ TARGET_THUMB1 arm_arch6
+ revsh\t%0, %1
+ [(set_attr length 2)]
+)
+
+(define_insn *thumb1_rev16
+ [(set (match_operand:HI 0 s_register_operand =l)
+ (bswap:HI (match_operand:HI 1 s_register_operand l)))]
+ TARGET_THUMB1 arm_arch6
+ rev16\t%0, %1
+ [(set_attr length 2)]
+)
+
(define_expand arm_legacy_rev
[(set (match_operand:SI 2 s_register_operand )
(xor:SI (rotatert:SI (match_operand:SI 1 s_register_operand )
@@ -11420,6 +11454,13 @@
)
+(define_expand bswaphi2
+ [(set (match_operand:HI 0 s_register_operand =r)
+ (bswap:HI (match_operand:HI 1 s_register_operand r)))]
+TARGET_EITHER (arm_arch6)
+
+)
+
;; Load the load/store multiple patterns
(include ldmstm.md)
;; Load the FPA co-processor patterns
--
1.7.7.3
Re: [PATCH] Fix PR52977
On Apr 16, 2012, at 6:43 AM, Richard Guenther wrote: Well, the number one advantage of replacing PCH is that it would kill the current PCH implementation which is tied to our garbage collector... If compile speed isn't important to people, there is little reason to keep pch around. Once that decision is made, the rest is easy. For translation units that take 1 second to compile, the difference between 2s and 9s is 4.5x, though, with link time, the actual benefit drops significantly. I'd argue that the benefit of pch is worth the cost. As for bugs, pch was designed to be high quality, low maintenance, I think it achieves that goal. I've seen the effort required for pph and the number and types of bugs fixed, and my impression is that pch is but a pale shadow, compared to it. So, easier to implement, faster, fewer bugs, seems good to me. I do wish we have a more powerful language in which to express pch, so that the way pch impacts the compiler is reduced. As we move to C++, there might be an opportunity to re-craft how that interface is done, so as to eliminate even more of the cost of pch in the compiler. The cheaper the implementation is, I think the easier it is to retain pch. Ultimately, the best way to remove it, may be to craft a language level solution for the C family of languages, in which the cost of headers is engineered to be 0, or at least, very close to it. I'd encourage that solution, as then, we can rip out both pch and pph, which I think would be a good direction to move in. Now, long term, it is possible that with more cores than translation units, a full rebuild, no pph or pch of any type, would be the fastest and simplest implementation. We're not there yet, and I don't know if the lines of the two will cross... but many they will. Maybe power efficiency will matter even in that case, so maybe pch will still be useful.
Re: [PATCH] Atom: Scheduler improvements for better imul placement
On Fri, Apr 13, 2012 at 4:20 PM, Andrey Belevantsev a...@ispras.ru wrote: On 13.04.2012 14:18, Igor Zamyatin wrote: On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantseva...@ispras.ru wrote: On 12.04.2012 16:38, Richard Guenther wrote: On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatinizamya...@gmail.com wrote: On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther richard.guent...@gmail.com wrote: On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakovamona...@ispras.ru wrote: Can atom execute two IMUL in parallel? Or what exactly is the pipeline behavior? As I understand from Intel's optimization reference manual, the behavior is as follows: if the instruction immediately following IMUL has shorter latency, execution is stalled for 4 cycles (which is IMUL's latency); otherwise, a 4-or-more cycles latency instruction can be issued after IMUL without a stall. In other words, IMUL is pipelined with respect to other long-latency instructions, but not to short-latency instructions. It seems to be modeled in the pipeline description though: ;;; imul insn has 5 cycles latency (define_reservation atom-imul-32 atom-imul-1, atom-imul-2, atom-imul-3, atom-imul-4, atom-port-0) ;;; imul instruction excludes other non-FP instructions. (exclusion_set atom-eu-0, atom-eu-1 atom-imul-1, atom-imul-2, atom-imul-3, atom-imul-4) The main idea is quite simple: If we are going to schedule IMUL instruction (it is on the top of ready list) we try to find out producer of other (independent) IMUL instruction that is in ready list too. The goal is try to schedule such a producer to get another IMUL in ready list and get scheduling of 2 successive IMUL instructions. Why does that not happen without your patch? Does it never happen without your patch or does it merely not happen for one EEMBC benchmark (can you provide a testcase?)? It does not happen because the scheduler by itself does not do such specific reordering. That said, it is easy to imagine the cases where this patch will make things worse rather than better. Igor, why not try different subtler mechanisms like adjust_priority, which is get called when an insn is added to the ready list? E.g. increase the producer's priority. The patch as is misses checks for NONDEBUG_INSN_P. Also, why bail out when you have more than one imul in the ready list? Don't you want to bump the priority of the other imul found? Could you provide some examples when this patch would harm the performance? I thought of the cases when the other ready insns can fill up the hole and that would be more beneficial because e.g. they would be on more critical paths than the producer of your second imul. I don't know enough of Atom to give an example -- maybe some long divisions? Sched_reorder was chosen since it is used in other ports and looks most suitable for such case, e.g. it provides access to the whole ready list. BTW, just increasing producer's priority seems to be more risky in performance sense - we can incorrectly start delaying some instructions. Yes, but exactly because of the above example you can start incorrectly delaying other insns, too, as you force the insn to be the first in the list. While bumping priority still leaves the scheduler sorting heuristics in place and actually lowers that risk. Thought ready list doesn't contain DEBUG_INSN... Is it so? If it contains them - this could be added easily It does, but I'm not sure the sched_reorder hook gets them or they are immediately removed -- I saw similar checks in one of the targets' hooks. Done with DEBUG_INSN, also 1-imul limit was removed. Patch attached Anyways, my main thought was that it is better to test on more benchmarks to alleviate the above concerns, so as long as the i386 maintainers are happy, I don't see major problems here. A good idea could be to generalize the patch to handle other long latency insns as second consumers, not only imuls, if this is relevant for Atom. Yes, generalization of this approach is in plans. According to Atom Software optimization guide there are several headrooms left here. As for trying on more benchmarks - the particular case is indeed quite rare. I attached the example where patch helps to group imuls in pairs which is profitable for Atom. Such and similar codes are not very common. But hopefully this approach could help avoid this and other glassjaws. Andrey The case with more than one imul in the ready list wasn't considered just because the goal was to catch the particular case when there is a risk to get the following picture: imul-producer-imul which is less effective than producer-imul-imul for Atom Andrey And MD allows us only prefer scheduling of successive IMUL instructions, i.e. If IMUL was just scheduled and ready list contains another IMUL instruction then it will be chosen as the
Re: Propagate profile counts after switch case expansion (issue5896043)
Ping. On Mon, Apr 9, 2012 at 2:33 PM, Easwaran Raman era...@google.com wrote: On Sun, Mar 25, 2012 at 9:40 PM, Easwaran Raman era...@google.com wrote: On Sun, Mar 25, 2012 at 12:22 PM, Jan Hubicka hubi...@ucw.cz wrote: This patch propagates execution count of thee case labels of a switch-case statement after its expansion. Bootstraps and all tests pass. OK for trunk? Hi, while this is resonable thing to do, I belive it would make most sense to make switch lowering at gimple level: i.e. reorganize the existing code to produce gimple statement and change expansion code to produce tablejump from every gimple switch statement that was left in the code. This would be both cleaner and would allow gimple optimizers to improve the generated code. Incrementally it would also allow us to improve switch exansion that is quite baroque and not realy producing very good code in some common cases. If you would be interested working on this (i.e. reorganizing the expansion code to produce gimple), I would be very happy. If not, I can review the profile updating part for mainline, since in any case this is desriable thing to do. I am planning to explore improvements to switch expansion (peeling some cases and using jump tables for the rest, for example) and I think the reorganization you suggest is the right way to do such improvements. But until I can spend time on it and get it done, I would like this patch to get reviewed and checked in. Thanks, Easwaran Ping.
C++ PATCH for c++/38543 (specialization of variadic function template)
The old code that compares the number of parameter types doesn't work in
the age of variadic templates. Instead, we should take the deduced
template arguments, substitute them in, and see if the result is what
we're looking for.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 84857b9698edb306e9659b1cc3a9f63829689db3
Author: Jason Merrill ja...@redhat.com
Date: Mon Apr 16 13:32:36 2012 -0400
PR c++/38543
* pt.c (determine_specialization): Instead of comparing the number
of parms, check that tsubst gives the right answer.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 171acb7..92c2326 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1839,6 +1839,7 @@ determine_specialization (tree template_id,
{
tree decl_arg_types;
tree fn_arg_types;
+ tree insttype;
/* In case of explicit specialization, we need to check if
the number of template headers appearing in the specialization
@@ -1900,15 +1901,6 @@ determine_specialization (tree template_id,
fn_arg_types
= skip_artificial_parms_for (fn, fn_arg_types);
- /* Check that the number of function parameters matches.
- For example,
- template class T void f(int i = 0);
- template void fint();
- The specialization fint is invalid but is not caught
- by get_bindings below. */
- if (list_length (fn_arg_types) != list_length (decl_arg_types))
- continue;
-
/* Function templates cannot be specializations; there are
no partial specializations of functions. Therefore, if
the type of DECL does not match FN, there is no
@@ -1929,6 +1921,15 @@ determine_specialization (tree template_id,
specialize TMPL will produce DECL. */
continue;
+ /* Make sure that the deduced arguments actually work. */
+ insttype = tsubst (TREE_TYPE (fn), targs, tf_none, NULL_TREE);
+ if (insttype == error_mark_node)
+ continue;
+ fn_arg_types
+ = skip_artificial_parms_for (fn, TYPE_ARG_TYPES (insttype));
+ if (!compparms (fn_arg_types, decl_arg_types))
+ continue;
+
/* Save this template, and the arguments deduced. */
templates = tree_cons (targs, fn, templates);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic131.C b/gcc/testsuite/g++.dg/cpp0x/variadic131.C
new file mode 100644
index 000..3006f87
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic131.C
@@ -0,0 +1,11 @@
+// PR c++/38543
+// { dg-do compile { target c++11 } }
+
+template typename ... T void foo( T ... args );
+template void foo( ){}
+template void foo(int,double){}
+int main()
+{
+ foo( 0, 0.0 );
+ return 55;
+}
Re: [Fortran] Patch ping
Thomas Koenig wrote: - [patch, fortran] Trim spaces on list-directed reads http://gcc.gnu.org/ml/fortran/2012-04/msg00040.html That one was committed: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00417.html Jerry indicated that this would also be OK for a backport; I'll do that within a few days unless there are objections. I prefer if you do not back port it. It is not a regression and it does not solve a serious deficit. It only seems to be for very special cases. In addition, the results shown by Dominique and Manfred support the caution: While there is no speedup, there is now the use of an uninitialized value. A more general question: I habe been a bit inconsistent in notifying the mailing list about committed patches; I didn't do this for these patches. What would people, generally, prefer? Should we notify on commit, or rather not? I think that it is usually not necessary as one can quickly check the ChangeLog(s) and usually the time between submittal, approval and committal is relatively short. But I don't mind if someone mentions at the mailing list the committal. On the other hand, committed as obvious committals should be send to the mailing list - with the patch. However, currently, the patch review is a bit shaky. Thus, I thought it makes sense to create a list of pending patches. * * * Updated list of pending patches: First, I would like to ping my patch: - [Patch, Fortran] PR52864 - fix actual/formal checks http://gcc.gnu.org/ml/fortran/2012-04/msg00059.html Other patches with pending review: - [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules http://gcc.gnu.org/ml/fortran/2012-04/msg00033.html Caveat: ABI breakage - [patch, fortran] PR fortran/52537 Optimize string comparisons against empty strings http://gcc.gnu.org/ml/fortran/2012-04/msg00068.html - [Patch, libfortran] Combine get_mem and internal_malloc_size http://gcc.gnu.org/ml/fortran/2012-03/msg00127.html Approved but not yet committed: My patch: - [Patch, Fortran] PR52864 - Fix pointer-intent regresssion http://gcc.gnu.org/ml/fortran/2012-04/msg00058.html http://gcc.gnu.org/ml/fortran/2012-04/msg00058.html (Backporting pending) Bernhard: - [PATCH] gfortran testsuite: implicitly cleanup-modules, part 2 http://gcc.gnu.org/ml/fortran/2012-04/msg00065.html Janne: - [Patch, fortran] PR 49010/24518 MOD/MODULO fixes http://gcc.gnu.org/ml/fortran/2012-04/msg00012.html Okayed but haven't found best wording. Tobias
[patch] Remove strange case cost code
Hello, There is code in stmt.c since the initial checkin, that tries to balance a switch tree according to some ascii heuristics. I see a couple of problems with this code: 1. It doesn't seem to help much. With the attached patch to remove the code, I see no compile time changes to e.g. compile GCC itself. 2. It isn't clear what the heuristic is based on (no reference to any testing done, or a reference to a book or paper). 3. The heuristic is applied for case values in the range -1,127 (inclusive) even if the type of the switch expression isn't char or int but e.g. an enum. This results in funny application of this heuristic in GCC itself to e.g. some cases of enum rtx_code and enum tree_code. The attached patch removes the heuristic. Bootstrapped and tested on powerpc-unknown-linux-gnu. OK for trunk? Ciao! Steven stmt_c_cleanup_1.diff Description: Binary data
Go patch committed: Avoid infinite recursion in string constant eval
This patch from Rémy Oudompheng avoids an infinite recursion in the Go
frontend when evaluating a string constant. It avoids a compiler crash
on invalid code like
const f, g = g, f
func S() []byte { return []byte(f) }
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 3271745b0eb0 go/expressions.cc
--- a/go/expressions.cc Wed Apr 04 11:49:50 2012 -0700
+++ b/go/expressions.cc Mon Apr 16 15:57:40 2012 -0700
@@ -2403,8 +2403,7 @@
do_numeric_constant_value(Numeric_constant* nc) const;
bool
- do_string_constant_value(std::string* val) const
- { return this-constant_-const_value()-expr()-string_constant_value(val); }
+ do_string_constant_value(std::string* val) const;
Type*
do_type();
@@ -2514,6 +2513,21 @@
return r;
}
+bool
+Const_expression::do_string_constant_value(std::string* val) const
+{
+ if (this-seen_)
+return false;
+
+ Expression* e = this-constant_-const_value()-expr();
+
+ this-seen_ = true;
+ bool ok = e-string_constant_value(val);
+ this-seen_ = false;
+
+ return ok;
+}
+
// Return the type of the const reference.
Type*
[C++ Patch] PR 53003
Hi,
I had a look to this Segmentation fault in cp_parser_member_declaration
and what happens is that initializer_token_start is still null (as
initialized) when we get to:
if (initializer)
error_at (initializer_token_start-location,
pure-specifier on function-definition);
the trivial check avoids the Seg fault (and would be safe, for 4.7 too)
but I'm not sure if we want to bail out a bit earlier. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2012-04-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/53003
* parser.c (cp_parser_member_declaration): Check that
initializer_token_start is non null before dereferencing it.
/testsuite
2012-04-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/53003
* g++.dg/parse/crash59.C: New.
Index: testsuite/g++.dg/parse/crash59.C
===
--- testsuite/g++.dg/parse/crash59.C(revision 0)
+++ testsuite/g++.dg/parse/crash59.C(revision 0)
@@ -0,0 +1,3 @@
+// PR c++/53003
+
+struct A{ void a{} return b // { dg-error function definition|expected }
Index: cp/parser.c
===
--- cp/parser.c (revision 186509)
+++ cp/parser.c (working copy)
@@ -19109,7 +19109,7 @@ cp_parser_member_declaration (cp_parser* parser)
possible that this fact is an oversight in the
standard, since a pure function may be defined
outside of the class-specifier. */
- if (initializer)
+ if (initializer initializer_token_start)
error_at (initializer_token_start-location,
pure-specifier on function-definition);
decl = cp_parser_save_member_function_body (parser,
C++ PATCH for c++/52008 (ICE with variadic partial specialization)
In this testcase, the partial specialization has fewer template
arguments than the primary template has parameters, which was confusing
GCC. Let's give an error for this case because the partial
specialization isn't more specialized than the primary template.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b7486132b037ea59ac7e6524085e4e765dc22852
Author: Jason Merrill ja...@redhat.com
Date: Mon Apr 16 12:49:13 2012 -0400
PR c++/52008
* pt.c (process_partial_specialization): Complain about a partial
specialization with fewer args than primary template parms.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index fcefc94..d6144d5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -4376,6 +4376,18 @@ process_partial_specialization (tree decl)
(maintmpl)
error (partial specialization %qT does not specialize any template arguments, type);
+ /* A partial specialization that replaces multiple parameters of the
+ primary template with a pack expansion is less specialized for those
+ parameters. */
+ if (nargs DECL_NTPARMS (maintmpl))
+{
+ error (partial specialization is not more specialized than the
+ primary template because it replaces multiple parameters
+ with a pack expansion);
+ inform (DECL_SOURCE_LOCATION (maintmpl), primary template here);
+ return decl;
+}
+
/* [temp.class.spec]
A partially specialized non-type argument expression shall not
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic130.C b/gcc/testsuite/g++.dg/cpp0x/variadic130.C
new file mode 100644
index 000..f73c8b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic130.C
@@ -0,0 +1,8 @@
+// PR c++/52008
+// { dg-do compile { target c++11 } }
+
+template int I, typename T, typename... Ts
+struct A;
+
+templatetypename... Ts
+struct A0, Ts...; // { dg-error not more specialized }
C++ PATCH for c++/50830 (another variadic template template parameter issue)
Here, we were getting confused and thinking that an argument pack of
template template arguments wasn't suitable for a template template
parameter pack. But it is.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6143aa83bb48ef7c9d2bbcb0dff13a964036b3d1
Author: Jason Merrill ja...@redhat.com
Date: Mon Apr 16 11:53:57 2012 -0400
PR c++/50830
* pt.c (convert_template_argument): Handle template template
argument packs.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7423781..fcefc94 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6428,6 +6428,7 @@ convert_template_argument (tree parm,
is_tmpl_type =
((TREE_CODE (arg) == TEMPLATE_DECL
TREE_CODE (DECL_TEMPLATE_RESULT (arg)) == TYPE_DECL)
+ || (requires_tmpl_type TREE_CODE (arg) == TYPE_ARGUMENT_PACK)
|| TREE_CODE (arg) == TEMPLATE_TEMPLATE_PARM
|| TREE_CODE (arg) == UNBOUND_CLASS_TEMPLATE);
@@ -6499,7 +6500,9 @@ convert_template_argument (tree parm,
{
if (requires_tmpl_type)
{
- if (TREE_CODE (TREE_TYPE (arg)) == UNBOUND_CLASS_TEMPLATE)
+ if (template_parameter_pack_p (parm) ARGUMENT_PACK_P (orig_arg))
+ val = orig_arg;
+ else if (TREE_CODE (TREE_TYPE (arg)) == UNBOUND_CLASS_TEMPLATE)
/* The number of argument required is not known yet.
Just accept it for now. */
val = TREE_TYPE (arg);
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic129.C b/gcc/testsuite/g++.dg/cpp0x/variadic129.C
new file mode 100644
index 000..7118301
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic129.C
@@ -0,0 +1,19 @@
+// PR c++/50830
+// { dg-do compile { target c++11 } }
+
+templatetemplateclass class...
+struct list_templates {};
+
+templateclass
+struct aa {};
+
+templateclass... T
+struct test {};
+
+templatetemplateclass class... F, class T
+struct testlist_templatesF..., T
+{
+struct inner {};
+};
+
+testlist_templatesaa, int a4; // error
C++ PATCH for c++/50303 (failure using template template parameter pack in a pack expansion)
When substituting into a template template parameter pack pattern with a
set of template arguments, we want to use tsubst_expr so that we get the
substituted result; tsubst tries and fails to build up a new template
template parameter.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d04f9e7b78c9355e7b7835dc00fca3dfa4acc666
Author: Jason Merrill ja...@redhat.com
Date: Mon Apr 16 11:31:59 2012 -0400
PR c++/50303
* pt.c (tsubst_pack_expansion): Use tsubst_expr for template
template parameters.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 95d0aba..7423781 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -9518,7 +9518,7 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,
}
/* Substitute into the PATTERN with the altered arguments. */
- if (TREE_CODE (t) == EXPR_PACK_EXPANSION)
+ if (!TYPE_P (pattern))
TREE_VEC_ELT (result, i) =
tsubst_expr (pattern, args, complain, in_decl,
/*integral_constant_expression_p=*/false);
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic128.C b/gcc/testsuite/g++.dg/cpp0x/variadic128.C
new file mode 100644
index 000..8c2d3b2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic128.C
@@ -0,0 +1,16 @@
+// PR c++/50303
+// { dg-do compile { target c++11 } }
+
+templatetypename Interface
+struct A1 {
+};
+
+templatetemplateclass I class... Actions
+void g2() {
+ g2Actions...();
+}
+
+int main()
+{
+ g2A1();
+}
