RE: [PATCH, reload] Fix bug pr52804, RELOAD pass reloads wrong register on ARM for cortex-m0
Ping. Hi, could anyone help me with this bug please, if you have time? Any comments will be appreciated. Thanks very much. > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Bin Cheng > Sent: Friday, April 20, 2012 1:51 PM > To: gcc-patches@gcc.gnu.org > Subject: [PATCH, reload] Fix bug pr52804, RELOAD pass reloads wrong register > on ARM for cortex-m0 > > Hi, > Previously I reported pr52804 in bugzilla about reload pass reloads wrong > register. > After investigation I believe it is a bug in reload pass and here comes the > patch. > You can refer to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 for details. > > In short, I think the confliction of reloads with type > RELOAD_FOR_INPADDR_ADDRESS and type RELOAD_FOR_INPUT_ADDRESS should be handled > in "reload_reg_reaches_end_p". > Also I think RELOAD_FOR_OUTPUT_ADDRESS/RELOAD_FOR_OUTADDR_ADDRESS have the > issue symmetrically, though I have no test case for it. > > I have tested the patch for x86 and arm. Is it OK? > > I think it is a bug of reload, and I understand reload pass should be rarely > touched, so any comments are highly appreciated on this topic. > > Thanks very much. > > > 2012-04-20 Bin Cheng > > PR target/52804 > * reload1.c (reload_reg_reaches_end_p): Check whether successor reload > with > type RELOAD_FOR_INPUT_ADDRESS kills reload register of current one with > type > RELOAD_FOR_INPADDR_ADDRESS.
Re: [Patch, fortran] PR41600 - [OOP] SELECT TYPE with associate-name => exp: Arrays not supported
Dear Tobias,
Thanks for completing the review. I should be able to commit tonight.
> Thanks for the patch. I think it is OK.
>
> Regarding:
>
>> ! if (ref&& ref->type != REF_ARRAY&& seen_array)
>> ! {
>> ! gfc_error ("CLASS selector at %L is an array with CLASS "
>> ! "components; this is not allowed since the "
>> ! "elements could have different dynamic types",
>> ! &target->where);
>
>
> Could you open a PR for it? If possible with a test case.
select_type_28.f03 is that testcase (see below). I am not sure what
the PR would be for - surely such selectors make no logical sense?
Oddly I can see no such restriction in the standard. Indeed, there
seems to me to be an identical diffculty with pointer assignment.
Maybe a message to clf would be in order?
Cheers
Paul
Cheers
Paul
implicit none
type t0
integer :: j = 42
end type t0
type, extends(t0) :: t1
integer :: k = 99
end type t1
type t
integer :: i
class(t0), allocatable :: foo
end type t
type(t) :: m(4)
integer :: n
do n = 1, 2
allocate(m(n)%foo, source = t0(n*99))
end do
do n = 3, 4
allocate(m(n)%foo, source = t1(n*99, n*999))
end do
! The class components 'foo' of m(1:2) now have a different dynamic
type to those of m(3:4)
! An array of objects with ultimate class components cannot be a selector
! since each element could have a different dynamic type.
select type(bar => m%foo) ! { dg-error "is an array with CLASS components" }
type is(t0)
if (any (bar%j .ne. [99, 198, 297, 396])) call abort
type is(t1)
call abort
end select
end
[PATCH] Fix overzealous DSE on sparc
On targets such as sparc, where ARG_POINTER_REGNUM ==
FRAME_POINTER_REGNUM, some of the invariants currently built into DSE
simply do not hold.
Unlike how DSE assumes, we will in fact see stores to frame pointer
relative addresses for setting up outgoing arguments to a CALL.
The result is that DSE can eliminate stores that setup those
arguments.
Two test cases and a DSE debugging dump for one of them can be found
at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
Richard and Kenneth, can you take a look at this? The patch is
against the 4.7 branch, which is where I've been tracking this down.
I'm currently running it through a regstrap and a glibc build (the
latter of which is where I originally saw this problem)
Thanks.
2012-05-01 David S. Miller
PR target/53684
* dse.c (scan_insn): When the frame pointer is used as the
argument pointer, mark non-const calls as frame_read.
--- gcc/dse.c~ 2012-05-01 20:27:48.163611555 -0700
+++ gcc/dse.c 2012-05-02 01:03:19.450719154 -0700
@@ -2646,10 +2646,17 @@ scan_insn (bb_info_t bb_info, rtx insn)
}
else
- /* Every other call, including pure functions, may read any memory
- that is not relative to the frame. */
-add_non_frame_wild_read (bb_info);
-
+ {
+ /* Every other call, including pure functions, may read any memory
+that is not relative to the frame. */
+ add_non_frame_wild_read (bb_info);
+#if FRAME_POINTER_REGNUM == ARG_POINTER_REGNUM
+ /* If the target uses the frame pointer as the argument
+pointer, then we will encounter frame relative stores
+that setup outgoing arguments to a function. */
+ insn_info->frame_read = true;
+#endif
+ }
return;
}
[patch] PR53153
Hello,
The attached patch fixes PR53153.
The problem is that tree-ssa-forwprop.c propagates away a cast, but
leaves out-of-range case labels in the switch. Before my patch for
r186579, the code in stmt.c would remove such case labels before any
of the RTL expanders got to see them. After my patch, the gimplifier
removed those out-of-range labels, but forwprop re-introduces them
and, en passant, makes the type of the switch index expression
different from the types of the case label values.
This patch adds splits out the case label preprocessing code in
gimplify.c to a new function, and makes forwprop use it to update the
switch label values if it changes the switch index type.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
gcc/
* gimplify.c (preprocess_case_label_vec_for_gimple): New function,
split out from ...
(gimplify_switch_expr): ... here.
* gimple.h (preprocess_case_label_vec_for_gimple): Add prototype.
* tree-ssa-forwprop.c (simplify_gimple_switch_label_vec): New function
to clean up case labels with values outside the index type range.
(simplify_gimple_switch): Call it if something changed.
Remove strange and unnecessary assert.
testsuite/
* gcc.dg/pr53153.c: New test.
Index: gimplify.c
===
--- gimplify.c (revision 186962)
+++ gimplify.c (working copy)
@@ -1538,7 +1538,7 @@ gimplify_statement_list (tree *expr_p, g
return GS_ALL_DONE;
}
-
+
/* Compare two case labels. Because the front end should already have
made sure that case ranges do not overlap, it is enough to only compare
the CASE_LOW values of each case label. */
@@ -1565,8 +1565,179 @@ sort_case_labels (VEC(tree,heap)* label_
{
VEC_qsort (tree, label_vec, compare_case_labels);
}
+
+/* Prepare a vector of case labels to be used in a GIMPLE_SWITCH statement.
+
+ LABELS is a vector that contains all case labels to look at.
+
+ INDEX_TYPE is the type of the switch index expression. Case labels
+ in LABELS are discarded if their values are not in the value range
+ covered by INDEX_TYPE. The remaining case label values are folded
+ to INDEX_TYPE.
+
+ If a default case exists in LABELS, it is removed from LABELS and
+ returned in DEFAULT_CASEP. If no default case exists, but the
+ case labels already cover the whole range of INDEX_TYPE, a default
+ case is returned pointing to one of the existing case labels.
+ Otherwise DEFAULT_CASEP is set to NULL_TREE.
+
+ DEFAULT_CASEP may be NULL, in which case the above comment doesn't
+ apply and no action is taken regardless of whether a default case is
+ found or not. */
-/* Gimplify a SWITCH_EXPR, and collect a TREE_VEC of the labels it can
+void
+preprocess_case_label_vec_for_gimple (VEC(tree,heap) *labels,
+ tree index_type,
+ tree *default_casep)
+{
+ tree min_value, max_value;
+ tree default_case = NULL_TREE;
+ size_t i, len;
+
+ i = 0;
+ min_value = TYPE_MIN_VALUE (index_type);
+ max_value = TYPE_MAX_VALUE (index_type);
+ while (i < VEC_length (tree, labels))
+{
+ tree elt = VEC_index (tree, labels, i);
+ tree low = CASE_LOW (elt);
+ tree high = CASE_HIGH (elt);
+ bool remove_element = FALSE;
+
+ if (low)
+ {
+ gcc_checking_assert (TREE_CODE (low) == INTEGER_CST);
+ gcc_checking_assert (!high || TREE_CODE (high) == INTEGER_CST);
+
+ /* This is a non-default case label, i.e. it has a value.
+
+See if the case label is reachable within the range of
+the index type. Remove out-of-range case values. Turn
+case ranges into a canonical form (high > low strictly)
+and convert the case label values to the index type.
+
+NB: The type of gimple_switch_index() may be the promoted
+type, but the case labels retain the original type. */
+
+ if (high)
+ {
+ /* This is a case range. Discard empty ranges.
+If the bounds or the range are equal, turn this
+into a simple (one-value) case. */
+ int cmp = tree_int_cst_compare (high, low);
+ if (cmp < 0)
+ remove_element = TRUE;
+ else if (cmp == 0)
+ high = NULL_TREE;
+ }
+
+ if (! high)
+ {
+ /* If the simple case value is unreachable, ignore it. */
+ if ((TREE_CODE (min_value) == INTEGER_CST
+ && tree_int_cst_compare (low, min_value) < 0)
+ || (TREE_CODE (max_value) == INTEGER_CST
+ && tree_int_cst_compare (low, max_value) > 0))
+ remove_element = TRUE;
+ else
+ low = fold_convert (index_type, low);
+ }
+ else
+ {
+ /*
Re: [PATCH] teach phi-opt to produce -(a COND b)
On Tue, 1 May 2012, Richard Henderson wrote: > On 04/27/2012 03:01 AM, Paolo Bonzini wrote: > > This patch teaches phiopt to look at phis whose arguments are -1 and 0, > > and produce negated setcc statements. > > Is this really a win over a COND_EXPR, i.e. (a < b ? -1 : 0)? > > There is quite a bit of logic inside the rtl and backend expansion of > cmove that would seem to be being bypassed by committing to this form. Well, it's a choice of representation on GIMPLE. Allowing COND_EXPRs on the RHS is quite new (and does not play well with standard optimization passes). If RTL expansion logic prefers COND_EXPRs over the CFG/PHI style then we should see to present it with COND_EXPRs when we go out of SSA form (well we don't, but we do SSA name partitioning and certainly at that time we should adjust/optimize PHI nodes - also re-instantiating the now missing feature of splitting blocks to enable PHI argument CSE). Richard.
Re: [PATCH RFC] Warn when optimization flag is given without -O
On Sat, Apr 28, 2012 at 4:48 PM, Alexander Monakov wrote: > > Looks like people who want to play with optimization options are still tripped > by the fact that optimizations are not enabled unless -O is given (even though > it's documented in the manual now). Can we add a warning for that like below? > > Untested beside bubblestrap. I suppose this will produce noise for -O0 > torture testsuite — what is the recommended way to fix that? > > diff --git a/gcc/opts-common.c b/gcc/opts-common.c > index 354bce0..a18a89d 100644 > --- a/gcc/opts-common.c > +++ b/gcc/opts-common.c > @@ -1056,6 +1056,11 @@ read_cmdline_option (struct gcc_options *opts, > if (!handle_option (opts, opts_set, decoded, lang_mask, DK_UNSPECIFIED, > loc, handlers, false, dc)) > error_at (loc, "unrecognized command line option %qs", opt); > + > + if ((option->flags & CL_OPTIMIZATION) That's surely too coarse - you will warn about options that _will_ have an effect. There is currently no easy way to glob all affected options. I don't think we want to warn about -O2 -ftree-pre -O0 either, nor about -fno-tree-pre. Overall I would expect people to have noticed that with -O0 these options have no effect when they've gone all the way to figure out the separate optimization options, no? Thanks, Richard. > + && !opts->x_optimize) > + warning_at (loc, 0, "optimization option %qs has no effect " > + "at zero -O level", opt); > } > > /* Set any field in OPTS, and OPTS_SET if not NULL, for option
Re: Optimize calls to functions that return one of their arguments
On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidt wrote: > This patch allows us to recognize that even if the argument to memcpy lives > across the call, we can allocate it to a call-used register by reusing the > return value of the function. > > First, the patch sets the existing "fn spec" attribute for memcpy/memmove. > This is translated to a new form of CALL_INSN_FUNCTION_USAGE, a (set > (returnreg) (argreg)). This is recognized by IRA to adjust costs, and for > communicating to caller-save that the register can be restored cheaply. > > The optimization only triggers if the argument is passed in a register, > which should be the case in the majority of sane ABIs. The effect on the new > testcase: > > pushq %rbx | subq $8, %rsp > movslq %edx, %rdx movslq %edx, %rdx > movq %rdi, %rbx < > call memcpy call memcpy > movq %rbx, %rax | addq $8, %rsp > popq %rbx < > ret ret > > Bootstrapped with all languages on i686-linux, and bootstrapped and tested > minus Ada on x86_64-linux. There's one Go test which seems to fail randomly > both with and without the patch: > FAIL: go.test/test/stack.go execution, -O2 -g > > Ok? Heh, interesting idea. I suppose you chose memcpy/memmove because the middle-end emits those for block moves? I see you've gone all the way generalizing support for this instead of a special hack (an RTL flag on the call, directly set by the expander?) for this case? I've chickened out at adding fnspec annotations to builtins because of the explosion of various strings that would need ;) That said, I like it but will leave the RTL / IRA parts to someone else to look at. Thanks, Richard. > > Bernd
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
> > Pascal, I'd suggest you go ahead and revert this patch. > > This patch has already been reverted by Eric on Apr 10 on gcc-4.7 branch. I'm talking about the FSF trunk repository. Arno
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
Arno, >> This patch has already been reverted by Eric on Apr 10 on gcc-4.7 branch. > > I'm talking about the FSF trunk repository. Ah ok, but I do not have commit access to this repository. Eric maybe? -- Pascal Obry -- gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
> > I'm talking about the FSF trunk repository. > > Ah ok, but I do not have commit access to this repository. Eric maybe? If you send me a patch with changelog, I'll take care of it. Arno
Re: [PATCH] Don't ignore compute_all_dependences failures in phiopt (PR tree-optimization/53163)
On Mon, Apr 30, 2012 at 3:39 PM, Jakub Jelinek wrote:
> Hi!
>
> compute_all_dependences in 4.7+ can fail, and cond_if_else_store_replacement
> isn't prepared to handle the chrec_dont_know DDR added there in case of
> failure (with NULL DDR_A/DDR_B).
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk/4.7?
Ok.
> BTW, tree-ssa-loop-prefetch.c seems to have the same problem, but no idea
> how that should be handled in there...
I think it handles it fine by treating the chrec_dont_know DDR
properly? I suppose
failing would be an option, too, by returning a bool from
determine_loop_nest_reuse
and adjusting its single caller.
Thanks,
Richard.
> 2012-04-30 Jakub Jelinek
>
> PR tree-optimization/53163
> * tree-ssa-phiopt.c (cond_if_else_store_replacement): Don't ignore
> return value from compute_all_dependences.
>
> * gcc.c-torture/compile/pr53163.c: New test.
>
> --- gcc/tree-ssa-phiopt.c.jj 2012-04-30 08:06:18.0 +0200
> +++ gcc/tree-ssa-phiopt.c 2012-04-30 08:59:16.726488101 +0200
> @@ -1624,8 +1624,17 @@ cond_if_else_store_replacement (basic_bl
> /* Compute and check data dependencies in both basic blocks. */
> then_ddrs = VEC_alloc (ddr_p, heap, 1);
> else_ddrs = VEC_alloc (ddr_p, heap, 1);
> - compute_all_dependences (then_datarefs, &then_ddrs, NULL, false);
> - compute_all_dependences (else_datarefs, &else_ddrs, NULL, false);
> + if (!compute_all_dependences (then_datarefs, &then_ddrs, NULL, false)
> + || !compute_all_dependences (else_datarefs, &else_ddrs, NULL, false))
> + {
> + free_dependence_relations (then_ddrs);
> + free_dependence_relations (else_ddrs);
> + free_data_refs (then_datarefs);
> + free_data_refs (else_datarefs);
> + VEC_free (gimple, heap, then_stores);
> + VEC_free (gimple, heap, else_stores);
> + return false;
> + }
> blocks[0] = then_bb;
> blocks[1] = else_bb;
> blocks[2] = join_bb;
> --- gcc/testsuite/gcc.c-torture/compile/pr53163.c.jj 2012-04-30
> 09:21:40.950512562 +0200
> +++ gcc/testsuite/gcc.c-torture/compile/pr53163.c 2012-04-30
> 09:21:20.0 +0200
> @@ -0,0 +1,34 @@
> +/* PR tree-optimization/53163 */
> +
> +struct S { int s; } b, f;
> +int a, c;
> +
> +void
> +foo (void)
> +{
> + int d, e;
> + for (d = 4; d < 19; ++d)
> + for (e = 2; e >= 0; e--)
> + {
> + a = 0;
> + a = 1;
> + }
> +}
> +
> +void
> +bar (void)
> +{
> + int g, h, i;
> + for (i = 1; i >= 0; i--)
> + {
> + b = f;
> + for (g = 0; g <= 1; g++)
> + {
> + if (c)
> + break;
> + for (h = 0; h <= 1; h++)
> + foo ();
> + foo ();
> + }
> + }
> +}
>
> Jakub
Re: [PATCH 1/2] Minor refactoring of tree-vect-patterns.c
On Mon, Apr 30, 2012 at 6:19 PM, Ulrich Weigand wrote:
> Hello,
>
> in working on a fix for PR 52633, I noticed that tree-vect-patterns.c now
> contains a number of copies of rather similar code (of which my patch
> would have added another copy), so it seems to make sense to do a bit of
> refactoring first.
>
> This patch introduced a new helper function "vect_same_loop_or_bb_p"
> to decide whether a new statement is in the same loop or basic-block
> (depending on whether we're currently doing loop-based or basic-block-based
> vectorization) as an existing statement. The helper is then used everywhere
> where this test is currently open-coded.
>
> As a side-effect, the patch actually contains two bug fixes:
>
> - The condition in some places
> (!loop && gimple_bb (def_stmt) != BB_VINFO_BB (bb_vinfo)
> && gimple_code (def_stmt) != GIMPLE_PHI)
>
> doesn't seem to make sense. It allows PHI statements from random
> other basic blocks -- but those will have an uninitialized
> vinfo_for_stmt, so if that test ever hits, we're going to crash.
>
> The check was introduced in this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00191.html
>
> which likewise introduces a similar check in vect_get_and_check_slp_defs:
>
> (!loop && gimple_bb (def_stmt) == BB_VINFO_BB (bb_vinfo)
> && gimple_code (def_stmt) != GIMPLE_PHI))
>
> This makes sense: basic-block vectorization operates only on statements
> in the current basic block, but *not* on the incoming PHIs.
>
> It seems that the condition simply was incorrectly negated when moving
> it over to the tree-vect-pattern.c uses.
>
>
> - In vect_recog_widen_shift_pattern, the test for same loop / basic-block
> is still missing. In my recent patch to PR 52870 I added the check to
> vect_recog_widen_mult_pattern ... it is still missing in ...shift_pattern.
>
>
> Tested on i386-linux-gnu and arm-linux-gnueabi with no regressions.
>
> OK for mainline?
Ok.
Thanks,
Richard.
> Bye,
> Ulrich
>
>
> ChangeLog:
>
> * tree-vect-patterns.c (vect_same_loop_or_bb_p): New function.
> (vect_handle_widen_op_by_const): Use it instead of open-coding test.
> (vect_recog_widen_mult_pattern): Likewise.
> (vect_operation_fits_smaller_type): Likewise.
> (vect_recog_over_widening_pattern): Likewise.
> (vect_recog_widen_shift_pattern): Add to vect_same_loop_or_bb_p test.
>
>
> Index: gcc-head/gcc/tree-vect-patterns.c
> ===
> --- gcc-head.orig/gcc/tree-vect-patterns.c 2012-04-26 15:53:48.0
> +0200
> +++ gcc-head/gcc/tree-vect-patterns.c 2012-04-26 19:46:12.0 +0200
> @@ -84,6 +84,41 @@ new_pattern_def_seq (stmt_vec_info stmt_
> append_pattern_def_seq (stmt_info, stmt);
> }
>
> +/* Check whether STMT2 is in the same loop or basic block as STMT1.
> + Which of the two applies depends on whether we're currently doing
> + loop-based or basic-block-based vectorization, as determined by
> + the vinfo_for_stmt for STMT1 (which must be defined).
> +
> + If this returns true, vinfo_for_stmt for STMT2 is guaranteed
> + to be defined as well. */
> +
> +static bool
> +vect_same_loop_or_bb_p (gimple stmt1, gimple stmt2)
> +{
> + stmt_vec_info stmt_vinfo = vinfo_for_stmt (stmt1);
> + loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
> + bb_vec_info bb_vinfo = STMT_VINFO_BB_VINFO (stmt_vinfo);
> +
> + if (!gimple_bb (stmt2))
> + return false;
> +
> + if (loop_vinfo)
> + {
> + struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
> + if (!flow_bb_inside_loop_p (loop, gimple_bb (stmt2)))
> + return false;
> + }
> + else
> + {
> + if (gimple_bb (stmt2) != BB_VINFO_BB (bb_vinfo)
> + || gimple_code (stmt2) == GIMPLE_PHI)
> + return false;
> + }
> +
> + gcc_assert (vinfo_for_stmt (stmt2));
> + return true;
> +}
> +
> /* Check whether NAME, an ssa-name used in USE_STMT,
> is a result of a type promotion or demotion, such that:
> DEF_STMT: NAME = NOP (name0)
> @@ -400,16 +435,6 @@ vect_handle_widen_op_by_const (gimple st
> {
> tree new_type, new_oprnd, tmp;
> gimple new_stmt;
> - loop_vec_info loop_vinfo;
> - struct loop *loop = NULL;
> - bb_vec_info bb_vinfo;
> - stmt_vec_info stmt_vinfo;
> -
> - stmt_vinfo = vinfo_for_stmt (stmt);
> - loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
> - bb_vinfo = STMT_VINFO_BB_VINFO (stmt_vinfo);
> - if (loop_vinfo)
> - loop = LOOP_VINFO_LOOP (loop_vinfo);
>
> if (code != MULT_EXPR && code != LSHIFT_EXPR)
> return false;
> @@ -425,12 +450,10 @@ vect_handle_widen_op_by_const (gimple st
> return true;
> }
>
> - if (TYPE_PRECISION (type) < (TYPE_PRECISION (*half_type) * 4)
> - || !gimple_bb (def_stmt)
> - || (loop && !flow_bb_inside_loop_p (loop, gimple_bb (def_stmt)))
> - || (!loop && gimple_bb (def_stmt) != BB_VINFO_BB (bb_vinfo)
> - && gimple_code (def_stmt) !=
Re: [PATCH 2/2] Minor refactoring of tree-vect-patterns.c
On Mon, Apr 30, 2012 at 6:19 PM, Ulrich Weigand wrote:
> Hello,
>
> as a second step in refactoring this patch introduces a routine
> vect_find_single_use to determine whether a defining statement
> has one single use within the current vectorization domain.
>
> The helper is then called wherever that check is currently
> open-coded. There should be no change in behaviour.
>
> Tested on i386-linux-gnu and arm-linux-gnueabi with no regressions.
>
> OK for mainline?
You can use single_imm_use to avoid the loop and simplify the factored
routine.
Ok with that change.
Thanks,
Richard.
> Bye,
> Ulrich
>
>
> ChangeLog:
>
> * tree-vect-patterns.c (vect_find_single_use): New function.
> (vect_recog_widen_mult_pattern): Use it instead of open-coding loop.
> (vect_recog_over_widening_pattern): Likewise.
> (vect_recog_widen_shift_pattern): Likewise.
>
>
> Index: gcc-head/gcc/tree-vect-patterns.c
> ===
> --- gcc-head.orig/gcc/tree-vect-patterns.c 2012-04-26 19:46:12.0
> +0200
> +++ gcc-head/gcc/tree-vect-patterns.c 2012-04-26 19:46:53.0 +0200
> @@ -119,6 +119,33 @@ vect_same_loop_or_bb_p (gimple stmt1, gi
> return true;
> }
>
> +/* If the LHS of DEF_STMT has a single use, and that statement is
> + in the same loop or basic block, return it. */
> +
> +static gimple
> +vect_find_single_use (gimple def_stmt)
> +{
> + tree lhs = gimple_assign_lhs (def_stmt);
> + imm_use_iterator imm_iter;
> + use_operand_p use_p;
> + gimple use_stmt = NULL;
> +
> + FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs)
> + {
> + if (is_gimple_debug (USE_STMT (use_p)))
> + continue;
> +
> + if (use_stmt)
> + return NULL;
> + use_stmt = USE_STMT (use_p);
> +
> + if (!vect_same_loop_or_bb_p (def_stmt, use_stmt))
> + return NULL;
> + }
> +
> + return use_stmt;
> +}
> +
> /* Check whether NAME, an ssa-name used in USE_STMT,
> is a result of a type promotion or demotion, such that:
> DEF_STMT: NAME = NOP (name0)
> @@ -636,31 +663,18 @@ vect_recog_widen_mult_pattern (VEC (gimp
> Use unsigned TYPE as the type for WIDEN_MULT_EXPR. */
> if (TYPE_UNSIGNED (type) != TYPE_UNSIGNED (half_type0))
> {
> - tree lhs = gimple_assign_lhs (last_stmt), use_lhs;
> - imm_use_iterator imm_iter;
> - use_operand_p use_p;
> - int nuses = 0;
> - gimple use_stmt = NULL;
> + gimple use_stmt;
> + tree use_lhs;
> tree use_type;
>
> if (TYPE_UNSIGNED (type) == TYPE_UNSIGNED (half_type1))
> return NULL;
>
> - FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs)
> - {
> - if (is_gimple_debug (USE_STMT (use_p)))
> - continue;
> - use_stmt = USE_STMT (use_p);
> - nuses++;
> - }
> -
> - if (nuses != 1 || !is_gimple_assign (use_stmt)
> - || gimple_assign_rhs_code (use_stmt) != NOP_EXPR)
> + use_stmt = vect_find_single_use (last_stmt);
> + if (!use_stmt || !is_gimple_assign (use_stmt)
> + || gimple_assign_rhs_code (use_stmt) != NOP_EXPR)
> return NULL;
>
> - if (!vect_same_loop_or_bb_p (last_stmt, use_stmt))
> - return NULL;
> -
> use_lhs = gimple_assign_lhs (use_stmt);
> use_type = TREE_TYPE (use_lhs);
> if (!INTEGRAL_TYPE_P (use_type)
> @@ -1165,10 +1179,7 @@ vect_recog_over_widening_pattern (VEC (g
> {
> gimple stmt = VEC_pop (gimple, *stmts);
> gimple pattern_stmt = NULL, new_def_stmt, prev_stmt = NULL, use_stmt = NULL;
> - tree op0, op1, vectype = NULL_TREE, lhs, use_lhs, use_type;
> - imm_use_iterator imm_iter;
> - use_operand_p use_p;
> - int nuses = 0;
> + tree op0, op1, vectype = NULL_TREE, use_lhs, use_type;
> tree var = NULL_TREE, new_type = NULL_TREE, tmp, new_oprnd;
> bool first;
> tree type = NULL;
> @@ -1192,18 +1203,8 @@ vect_recog_over_widening_pattern (VEC (g
> }
>
> /* STMT can be performed on a smaller type. Check its uses. */
> - lhs = gimple_assign_lhs (stmt);
> - nuses = 0;
> - FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs)
> - {
> - if (is_gimple_debug (USE_STMT (use_p)))
> - continue;
> - use_stmt = USE_STMT (use_p);
> - nuses++;
> - }
> -
> - if (nuses != 1 || !is_gimple_assign (use_stmt)
> - || !vect_same_loop_or_bb_p (stmt, use_stmt))
> + use_stmt = vect_find_single_use (stmt);
> + if (!use_stmt || !is_gimple_assign (use_stmt))
> return NULL;
>
> /* Create pattern statement for STMT. */
> @@ -1454,12 +1455,6 @@ vect_recog_widen_shift_pattern (VEC (gim
> Use unsigned TYPE as the type for WIDEN_LSHIFT_EXPR. */
> if (TYPE_UNSIGNED (type) != TYPE_UNSIGNED (half_type0))
> {
> - tree lhs = gimple_assign_lhs (last_stmt), use_lhs;
> - imm_use_iterator imm_iter;
> - use_operand_p use_p;
> - int nuses = 0;
> - tree use_type;
> -
> if
RFA: PR target/53120, constraint modifier "+" on operand tied by matching-constraint, "0".
Hi DJ, As pointed out by Hans-Peter in his patch for PR 53120 for the cris backend, the m32c/bitops.md file contains a pattern that uses both the "+" modifier and the "0" constraint. The patch below is a straightforward fix for this, replacing the "0" constraint with a match_dup. Tested with no regressions on an m32c-elf toolchain. OK to apply ? Cheers Nick gcc/ChangeLog 2012-05-02 Nick Clifton PR target/53120 * config/m32c/bitops.md (bset_qi): Change operand 2 from having a "0" constraint to being a (match_dup 0). Index: gcc/config/m32c/bitops.md === --- gcc/config/m32c/bitops.md (revision 187036) +++ gcc/config/m32c/bitops.md (working copy) @@ -43,7 +43,7 @@ [(set (match_operand:QI 0 "memsym_operand" "+Si") (ior:QI (subreg:QI (ashift:HI (const_int 1) (subreg:QI (match_operand:HI 1 "a_qi_operand" "Raa") 0)) 0) - (match_operand:QI 2 "memsym_operand" "0")))] + (match_dup 0)))] "TARGET_A16" "bset\t%0[%1]" [(set_attr "flags" "n")]
Re: [PATCH] Add -fdump-rtl--quiet
On 19/04/12 13:58, Andrew Stubbs wrote: In the meantime, Mr Maintainers, can I commit my patch while we wait for the new world order? I'm happy to change the option name "quiet" to something else if necessary. Ping. I think David may have a point about 'quiet' being an inappropriate name for this option. He proposed 'ir' which I don't like but will do the job just fine. Ok, with that change? Andrew
Re: Backported r185231 from trunk. (issue 6139063)
On Mon, Apr 30, 2012 at 9:54 PM, wrote:
> Reviewers: xur, davidxl, iant2,
>
> Message:
> I backported the following patch:
Btw, there were various followup commits fixing issues on some ports.
Richard.
> 2012-03-12 Richard Guenther
>
> * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
> * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
> (__gthread_mutex_init_function): New function.
> * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
>
> PR gcov/49484
> * libgcov.c: Include gthr.h.
> (__gcov_flush_mx): New global variable.
> (init_mx, init_mx_once): New functions.
> (__gcov_flush): Protect self with a mutex.
> (__gcov_fork): Re-initialize mutex after forking.
> * unwind-dw2-fde.c: Change condition under which to use
> __GTHREAD_MUTEX_INIT_FUNCTION.
>
>
>
> Please review this at http://codereview.appspot.com/6139063/
>
> Affected files:
> M .
> M gcc/ChangeLog.google-4_6
> M gcc/gthr-posix.h
> M gcc/gthr-single.h
> M gcc/gthr.h
> M gcc/libgcov.c
> M gcc/unwind-dw2-fde.c
> M libgcc/ChangeLog
>
>
> Index: .
> ===
> --- . (revision 186999)
> +++ . (working copy)
>
> Property changes on: .
> ___
> Modified: svn:mergeinfo
> Merged /trunk:r185231
> Index: libgcc/ChangeLog
> ===
> --- libgcc/ChangeLog (revision 186999)
> +++ libgcc/ChangeLog (working copy)
> @@ -1,3 +1,19 @@
> +2012-03-12 Richard Guenther
> +
> + * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
> + * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
> + (__gthread_mutex_init_function): New function.
> + * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
> +
> + PR gcov/49484
> + * libgcov.c: Include gthr.h.
> + (__gcov_flush_mx): New global variable.
> + (init_mx, init_mx_once): New functions.
> + (__gcov_flush): Protect self with a mutex.
> + (__gcov_fork): Re-initialize mutex after forking.
> + * unwind-dw2-fde.c: Change condition under which to use
> + __GTHREAD_MUTEX_INIT_FUNCTION.
> +
> 2012-03-01 Release Manager
>
> * GCC 4.6.3 released.
> Index: gcc/unwind-dw2-fde.c
> ===
> --- gcc/unwind-dw2-fde.c (revision 186999)
> +++ gcc/unwind-dw2-fde.c (working copy)
> @@ -46,11 +46,10 @@
>
> #ifdef __GTHREAD_MUTEX_INIT
> static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
> +#define init_object_mutex_once()
> #else
> static __gthread_mutex_t object_mutex;
> -#endif
>
> -#ifdef __GTHREAD_MUTEX_INIT_FUNCTION
> static void
> init_object_mutex (void)
> {
> @@ -63,8 +62,6 @@
> static __gthread_once_t once = __GTHREAD_ONCE_INIT;
> __gthread_once (&once, init_object_mutex);
> }
> -#else
> -#define init_object_mutex_once()
> #endif
>
> /* Called from crtbegin.o to register the unwind info for an object. */
> Index: gcc/ChangeLog.google-4_6
> ===
> --- gcc/ChangeLog.google-4_6 (revision 186999)
> +++ gcc/ChangeLog.google-4_6 (working copy)
> @@ -1,3 +1,22 @@
> +2012-02-21 Ahmad Sharif
> +
> + Backport from mainline r185231.
> + 2012-03-12 Richard Guenther
> +
> + * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
> + * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
> + (__gthread_mutex_init_function): New function.
> + * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
> +
> + PR gcov/49484
> + * libgcov.c: Include gthr.h.
> + (__gcov_flush_mx): New global variable.
> + (init_mx, init_mx_once): New functions.
> + (__gcov_flush): Protect self with a mutex.
> + (__gcov_fork): Re-initialize mutex after forking.
> + * unwind-dw2-fde.c: Change condition under which to use
> + __GTHREAD_MUTEX_INIT_FUNCTION.
> +
> 2012-04-25 Rong Xu
>
> * gcc/gcc.c (ripa_lto_spec): Support -S in streaming LIPO.
> Index: gcc/libgcov.c
> ===
> --- gcc/libgcov.c (revision 186999)
> +++ gcc/libgcov.c (working copy)
> @@ -46,6 +46,7 @@
> #include "tsystem.h"
> #include "coretypes.h"
> #include "tm.h"
> +#include "gthr.h"
> #endif /* __KERNEL__ */
>
> #if 1
> @@ -667,6 +668,26 @@
> info->version = 0;
> }
>
> +#ifdef __GTHREAD_MUTEX_INIT
> +ATTRIBUTE_HIDDEN __gthread_mutex_t __gcov_flush_mx = __GTHREAD_MUTEX_INIT;
> +#define init_mx_once()
> +#else
> +__gthread_mutex_t __gcov_flush_mx ATTRIBUTE_HIDDEN;
> +
> +static void
> +init_mx (void)
> +{
> + __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
> +}
> +static void
> +init_mx_once (void)
> +{
>
Re: [2/6] Fold prev/next into gimple: fewer gimple_seq_alloc calls
On Wed, May 2, 2012 at 3:06 AM, Michael Matz wrote:
> Hi,
>
> This patch gets rid of some easy gimple_seq_alloc calls that we don't even
> need currently because most gimple_seq modifier will lazily allocate one.
> Most of the time it's enough to simply initialize a seq to NULL and call
> the respective routines like gimple_seq_add_{stmt,seq}. (A notable
> exception is when the seq will be used in an iterator).
>
> As per [0/6] regstrapped together with the other five patches on
> x86_64-linux. Okay for trunk?
Ok.
Thanks,
Richard.
>
> Ciao,
> Michael.
>
> 2012-05-02 Michael Matz
>
> * tree-phinodes.c (add_phi_node_to_bb): Tidy, don't use
> gimple_seq_alloc.
> * omp-low.c (finalize_task_copyfn): Don't use gimple_seq_alloc.
> * tree-nested.c (walk_gimple_omp_for): Ditto.
> * trans-mem.c (lower_transaction): Ditto.
> * tree-eh.c (do_return_redirection): Ditto.
> (do_goto_redirection): Ditto.
> (lower_try_finally_switch): Ditto.
> * gimplify.c (gimplify_stmt): Ditto.
> (gimplify_scan_omp_clauses): Ditto.
> (gimplify_omp_for): Ditto.
> (gimplify_function_tree): Ditto.
> * gimple-fold.c (gimplify_and_update_call_from_tree): Ditto.
> * tree-mudflap.c (mf_decl_cache_locals): Ditto.
> (mf_build_check_statement_for): Ditto.
> (mx_register_decls): Ditto.
> * graphite-sese-to-poly.c (remove_invariant_phi): Ditto,
> and don't use itertors to append.
> (insert_stmts): Ditto.
> (insert_out_of_ssa_copy): Ditto.
> (insert_out_of_ssa_copy_on_edge): Ditto.
>
> Index: tree-phinodes.c
> ===
> *** tree-phinodes.c.orig 2012-05-01 22:43:34.0 +0200
> --- tree-phinodes.c 2012-05-01 22:43:55.0 +0200
> *** reserve_phi_args_for_new_edge (basic_blo
> *** 356,368
> void
> add_phi_node_to_bb (gimple phi, basic_block bb)
> {
> ! gimple_stmt_iterator gsi;
> /* Add the new PHI node to the list of PHI nodes for block BB. */
> ! if (phi_nodes (bb) == NULL)
> ! set_phi_nodes (bb, gimple_seq_alloc ());
> !
> ! gsi = gsi_last (phi_nodes (bb));
> ! gsi_insert_after (&gsi, phi, GSI_NEW_STMT);
>
> /* Associate BB to the PHI node. */
> gimple_set_bb (phi, bb);
> --- 356,370
> void
> add_phi_node_to_bb (gimple phi, basic_block bb)
> {
> ! gimple_seq seq = phi_nodes (bb);
> /* Add the new PHI node to the list of PHI nodes for block BB. */
> ! if (seq == NULL)
> ! set_phi_nodes (bb, gimple_seq_alloc_with_stmt (phi));
> ! else
> ! {
> ! gimple_seq_add_stmt (&seq, phi);
> ! gcc_assert (seq == phi_nodes (bb));
> ! }
>
> /* Associate BB to the PHI node. */
> gimple_set_bb (phi, bb);
> Index: omp-low.c
> ===
> *** omp-low.c.orig 2012-05-01 22:43:34.0 +0200
> --- omp-low.c 2012-05-01 22:43:55.0 +0200
> *** finalize_task_copyfn (gimple task_stmt)
> *** 1231,1237
> {
> struct function *child_cfun;
> tree child_fn, old_fn;
> ! gimple_seq seq, new_seq;
> gimple bind;
>
> child_fn = gimple_omp_task_copy_fn (task_stmt);
> --- 1231,1237
> {
> struct function *child_cfun;
> tree child_fn, old_fn;
> ! gimple_seq seq = NULL, new_seq;
> gimple bind;
>
> child_fn = gimple_omp_task_copy_fn (task_stmt);
> *** finalize_task_copyfn (gimple task_stmt)
> *** 1248,1260
> push_cfun (child_cfun);
> current_function_decl = child_fn;
> bind = gimplify_body (child_fn, false);
> - seq = gimple_seq_alloc ();
> gimple_seq_add_stmt (&seq, bind);
> new_seq = maybe_catch_exception (seq);
> if (new_seq != seq)
> {
> bind = gimple_build_bind (NULL, new_seq, NULL);
> ! seq = gimple_seq_alloc ();
> gimple_seq_add_stmt (&seq, bind);
> }
> gimple_set_body (child_fn, seq);
> --- 1248,1259
> push_cfun (child_cfun);
> current_function_decl = child_fn;
> bind = gimplify_body (child_fn, false);
> gimple_seq_add_stmt (&seq, bind);
> new_seq = maybe_catch_exception (seq);
> if (new_seq != seq)
> {
> bind = gimple_build_bind (NULL, new_seq, NULL);
> ! seq = NULL;
> gimple_seq_add_stmt (&seq, bind);
> }
> gimple_set_body (child_fn, seq);
> Index: tree-nested.c
> ===
> *** tree-nested.c.orig 2012-05-01 22:43:34.0 +0200
> --- tree-nested.c 2012-05-01 22:43:55.0 +0200
> *** walk_gimple_omp_for (gimple for_stmt,
> *** 617,623
>
> walk_body (callback_stmt, callback_op, info, gimple_omp_for_pre_body_ptr
> (for_stmt));
>
> ! seq = gimple_seq_alloc ();
> memset (&wi, 0, sizeof (wi));
> wi.info = info;
> wi.gsi = gsi_last (seq);
> --- 617,623
>
> walk_body (callback_stm
Re: [PATCH RFC] Warn when optimization flag is given without -O
On Wed, 2 May 2012, Richard Guenther wrote: > That's surely too coarse - you will warn about options that _will_ > have an effect. > There is currently no easy way to glob all affected options. Yeah, that's unfortunate. Do we want to have a separate flag (CL_OPTIMIZATION_O0) to mark such options? Apropos, following is a list of options that affect the list of produced dump files at O0. If someone knows an option that affects compilation at O0, but is not a part of this list, please let me know. -fbranch-probabilities -fbranch-target-load-optimize -fcombine-stack-adjustments -fexceptions -fhandle-exceptions -fschedule-insns -fsplit-wide-types -fvar-tracking-assignments -fvar-tracking-assignments-toggle > I don't think we want to warn about -O2 -ftree-pre -O0 either, nor Huh, I don't see why. Please explain? > about -fno-tree-pre. Yeah, that's an oversight in the patch, should be easy to fix. > Overall I would expect people to have noticed that with -O0 these options have > no effect when they've gone all the way to figure out the separate > optimization > options, no? At the moment people have two easy ways to find the list of optimization options (-fverbose-asm and --help=optimizers), but O0 issue is mentioned once not-quite-prominently in the manual and also in the FAQ in the wiki. In my opinion, the amount of times I've seen this issue come up warrants some effort on making it more visible (thus, a warning). Thanks Alexander
Re: [3/6] Fold prev/next into gimple
On Wed, May 2, 2012 at 3:14 AM, Michael Matz wrote:
> Hi,
>
> this introduces a new helper (gsi_replace_with_seq) which can replace a
> single statement with a sequence, and makes use of it in
> gimplify_and_update_call_from_tree. This make sure that the statements
> aren't inserted into the target sequence while they still are in the
> original one. Could also be solved by gsi_removing them just before
> inserting them, but this way seems much nicer.
>
> The tree-ssa-forwprop.c hunk ensures that when we remove the statement
> that the iterator (in the caller) pointing to it isn't invalidated. I
> think this was from earlier experiments of how to represent the data
> structures and might not be strictly needed anymore, but I've always
> tested with it, and it's definitely not harmful.
>
> As per [0/6] regstrapped with the other five on x86_64-linux. Okay for
> trunk?
>
>
> Ciao,
> Michael.
> --
> 2012-05-02 Michael Matz
>
> * gimple-fold.c (gimplify_and_update_call_from_tree): Use
> gsi_replace_with_seq, instead of inserting itself.
> * gimple-iterator.c (gsi_replace_with_seq): New function.
> * tree-ssa-forwprop.c (forward_propagate_comparison): Take
> iterator instead of statement, advance it.
> (ssa_forward_propagate_and_combine): Adjust call to above.
>
> Index: gimple-fold.c
> ===
> *** gimple-fold.c.orig 2012-05-01 22:44:02.0 +0200
> --- gimple-fold.c 2012-05-01 22:44:06.0 +0200
> *** gimplify_and_update_call_from_tree (gimp
> *** 551,557
> gimple_stmt_iterator i;
> gimple_seq stmts = NULL;
> struct gimplify_ctx gctx;
> - gimple last;
> gimple laststore;
> tree reaching_vuse;
>
> --- 551,556
> *** gimplify_and_update_call_from_tree (gimp
> *** 620,636
>
> /* Second iterate over the statements forward, assigning virtual
> operands to their uses. */
> - last = NULL;
> reaching_vuse = gimple_vuse (stmt);
> for (i = gsi_start (stmts); !gsi_end_p (i); gsi_next (&i))
> {
> - /* Do not insert the last stmt in this loop but remember it
> - for replacing the original statement. */
> - if (last)
> - {
> - gsi_insert_before (si_p, last, GSI_NEW_STMT);
> - gsi_next (si_p);
> - }
> new_stmt = gsi_stmt (i);
> /* The replacement can expose previously unreferenced variables. */
> if (gimple_in_ssa_p (cfun))
> --- 619,627
> *** gimplify_and_update_call_from_tree (gimp
> *** 642,648
> gimple_set_modified (new_stmt, true);
> if (gimple_vdef (new_stmt))
> reaching_vuse = gimple_vdef (new_stmt);
> - last = new_stmt;
> }
>
> /* If the new sequence does not do a store release the virtual
> --- 633,638
> *** gimplify_and_update_call_from_tree (gimp
> *** 659,666
> }
> }
>
> ! /* Finally replace rhe original statement with the last. */
> ! gsi_replace (si_p, last, false);
> }
>
> /* Return the string length, maximum string length or maximum value of
> --- 649,656
> }
> }
>
> ! /* Finally replace the original statement with the sequence. */
> ! gsi_replace_with_seq (si_p, stmts, false);
> }
>
> /* Return the string length, maximum string length or maximum value of
> Index: gimple-iterator.c
> ===
> *** gimple-iterator.c.orig 2012-05-01 22:43:34.0 +0200
> --- gimple-iterator.c 2012-05-01 22:44:06.0 +0200
> *** gsi_replace (gimple_stmt_iterator *gsi,
> *** 433,438
> --- 433,456
> update_modified_stmt (stmt);
> }
>
> + void
> + gsi_replace_with_seq (gimple_stmt_iterator *gsi, gimple_seq seq,
> + bool update_eh_info)
Ok with adding a proper function comment for this.
Thanks,
Richard.
> + {
> + gimple_stmt_iterator seqi;
> + gimple last;
> + if (gimple_seq_empty_p (seq))
> + {
> + gsi_remove (gsi, true);
> + return;
> + }
> + seqi = gsi_last (seq);
> + last = gsi_stmt (seqi);
> + gsi_remove (&seqi, false);
> + gsi_insert_seq_before (gsi, seq, GSI_SAME_STMT);
> + gsi_replace (gsi, last, update_eh_info);
> + }
> +
>
> /* Insert statement STMT before the statement pointed-to by iterator I.
> M specifies how to update iterator I after insertion (see enum
> Index: tree-ssa-forwprop.c
> ===
> *** tree-ssa-forwprop.c.orig 2012-05-01 22:39:07.0 +0200
> --- tree-ssa-forwprop.c 2012-05-01 22:44:06.0 +0200
> *** forward_propagate_addr_expr (tree name,
> *** 1202,1217
> }
>
>
> ! /* Forward propagate the comparison defined in STMT like
> cond_1 = x CMP y to uses of the form
> a_1 = (T')cond_1
> a_1 = !cond_1
> a_1 = cond_1 !=
Re: [PATCH] Don't ignore compute_all_dependences failures in phiopt (PR tree-optimization/53163)
On Wed, May 02, 2012 at 11:24:13AM +0200, Richard Guenther wrote:
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> > ok for trunk/4.7?
>
> Ok.
Thanks.
> > BTW, tree-ssa-loop-prefetch.c seems to have the same problem, but no idea
> > how that should be handled in there...
>
> I think it handles it fine by treating the chrec_dont_know DDR
> properly? I suppose
> failing would be an option, too, by returning a bool from
> determine_loop_nest_reuse
> and adjusting its single caller.
IMHO it will just segfault (I don't have a testcase though).
compute_all_dependences (datarefs, &dependences, vloops, true);
FOR_EACH_VEC_ELT (ddr_p, dependences, i, dep)
{
if (DDR_ARE_DEPENDENT (dep) == chrec_known)
continue;
ref = (struct mem_ref *) DDR_A (dep)->aux;
refb = (struct mem_ref *) DDR_B (dep)->aux;
if (DDR_ARE_DEPENDENT (dep) == chrec_dont_know
|| DDR_NUM_DIST_VECTS (dep) == 0)
{
/* If the dependence cannot be analyzed, assume that there might
* be
a reuse. */
dist = 0;
ref->independent_p = false;
refb->independent_p = false;
}
If compute_all_dependences above fails (returns false), then dependences
vector will contain just single chrec_dont_know element, but with DDR_A
(dep) == DDR_B (dep) == NULL. So the above will try to dereference both and
ICE before checking chrec_dont_know (and even if it wouldn't, there is
nothing to mark independent_p = false - supposedly everything should be
no longer independent_p).
Jakub
Re: [5/6] Fold prev/next into gimple
On Wed, May 2, 2012 at 3:28 AM, Michael Matz wrote:
> Hi,
>
> this patch basically is the one that makes all interfaces that possibly
> change a gimple_seq take a pointer to one, this time _including_ the
> statement iterator.
>
> For that I opted to use the same idiom as our basic block edge iterators,
> namely via a wrapper macro that replaces the current gsi_start, and
> expands to "gsi_start_1 (&x)".
>
> This means that now even an writable iterator can be formed from an empty
> list, which is magically filled when things are added via that iterator.
> This is the reason why the first patch made sure that the gsi_start calls
> only receive lvalues. And this means also that the gimple_seq_alloc calls
> can be moved even more down to the low-level helpers.
>
> I add some XXX remarks with this patch, for which I have already another
> patch fixing them again. But it's not part of this series, so please bear
> with me.
>
> This should still be a functional no-op, as should be the whole 1-5
> sequence of patches. As per [0/6] regstrapped with the other five on
> x86_64-linux. Okay for trunk?
Ok.
Thanks,
Richard.
>
> Ciao,
> Michael.
>
> 2012-05-02 Michael Matz
>
> * gimple.h (gimple_stmt_iterator ): Make it be pointer to
> gimple_seq.
> (gimple_seq_set_last, gimple_seq_set_first): Take pointer to
> sequence, lazily allocate it.
> (bb_seq_addr): New function.
> (gsi_start_1): Rename from gsi_start, but take pointer to sequence.
> (gsi_start): Macro to wrap gsi_start_1 taking pointer of argument.
> (gsi_none): New function.
> (gsi_start_bb): Adjust.
> (gsi_last_1): Rename from gsi_last, but take pointer to sequence.
> (gsi_last): Macro to wrap gsi_last_1 taking pointer of argument.
> (gsi_last_bb): Adjust.
> (gsi_seq): Adjust.
> * tree-flow-inline.h (phi_nodes_ptr): New function.
>
> * gimple-iterator.c (gsi_insert_seq_nodes_before): Adjust to
> datastructure and interface change.
> (gsi_insert_seq_before_without_update): Ditto.
> (gsi_insert_seq_nodes_after): Ditto.
> (gsi_insert_seq_after_without_update): Ditto.
> (gsi_split_seq_after): Ditto, don't use gimple_seq_alloc.
> (gsi_split_seq_before): Ditto.
> (gsi_start_phis): Adjust.
> * tree-vect-loop.c (vect_determine_vectorization_factor): Use
> gsi_none.
> (vect_transform_loop): Ditto.
> * gimple.c (gimple_seq_add_stmt, gimple_seq_add_seq,
> gimple_seq_copy): Don't use gimple_seq_alloc.
> * gimplify.c (gimple_seq_add_stmt_without_update): Ditto.
> (gimplify_seq_add_seq): Ditto.
> * lto-streamer-in.c (make_new_block): Ditto.
> * tree-cfg.c (create_bb): Ditto.
> * tree-sra.c (initialize_parameter_reductions): Ditto.
>
> Index: gimple.h
> ===
> *** gimple.h.orig 2012-05-01 22:44:15.0 +0200
> --- gimple.h 2012-05-01 22:44:17.0 +0200
> *** typedef struct
> *** 165,171
> are necessary to handle edge cases such as when statement is
> added to an empty basic block or when the last statement of a
> block/sequence is removed. */
> ! gimple_seq seq;
> basic_block bb;
> } gimple_stmt_iterator;
>
> --- 165,171
> are necessary to handle edge cases such as when statement is
> added to an empty basic block or when the last statement of a
> block/sequence is removed. */
> ! gimple_seq *seq;
> basic_block bb;
> } gimple_stmt_iterator;
>
> *** gimple_seq_last_stmt (const_gimple_seq s
> *** 1070,1090
> }
>
>
> ! /* Set the last node in GIMPLE sequence S to LAST. */
>
> static inline void
> ! gimple_seq_set_last (gimple_seq s, gimple_seq_node last)
> {
> ! s->last = last;
> }
>
>
> ! /* Set the first node in GIMPLE sequence S to FIRST. */
>
> static inline void
> ! gimple_seq_set_first (gimple_seq s, gimple_seq_node first)
> {
> ! s->first = first;
> }
>
>
> --- 1070,1094
> }
>
>
> ! /* Set the last node in GIMPLE sequence *PS to LAST. */
>
> static inline void
> ! gimple_seq_set_last (gimple_seq *ps, gimple_seq_node last)
> {
> ! if (!*ps)
> ! *ps = gimple_seq_alloc ();
> ! (*ps)->last = last;
> }
>
>
> ! /* Set the first node in GIMPLE sequence *PS to FIRST. */
>
> static inline void
> ! gimple_seq_set_first (gimple_seq *ps, gimple_seq_node first)
> {
> ! if (!*ps)
> ! *ps = gimple_seq_alloc ();
> ! (*ps)->first = first;
> }
>
>
> *** bb_seq (const_basic_block bb)
> *** 1125,1130
> --- 1129,1139
> return (!(bb->flags & BB_RTL) && bb->il.gimple) ? bb->il.gimple->seq :
> NULL;
> }
>
> + static inline gimple_seq *
> + bb_seq_addr (const_basic_block bb)
> + {
> + return (!(bb->flags & BB_RTL) && bb->il.gimple) ? &bb->il.gimple->seq :
> NULL;
> + }
>
> /* Sets the sequence of state
Re: [committed] Run DImode atomic tests on ppc64
Hello!
> * lib/target-supports.exp
> (check_effective_target_sync_long_long_runtime): True for
> check_effective_target_powerpc64.
@@ -3795,6 +3795,8 @@ proc check_effective_target_sync_long_long_runtime { } {
&& [check_effective_target_lp64]
&& [check_effective_target_ultrasparc_hw]) } {
return 1
+} elseif { [check_effective_target_powerpc64] } {
+ return 1
} else {
return 0
}
A check_effective_target_lp64 test is needed, otherwise -m32 won't
work correctly. Please see [1] for introduced failures.
[1] http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00091.html
Uros.
Re: [patch] PR53153
On Wed, May 2, 2012 at 10:32 AM, Steven Bosscher wrote: > Hello, > > The attached patch fixes PR53153. > > The problem is that tree-ssa-forwprop.c propagates away a cast, but > leaves out-of-range case labels in the switch. Before my patch for > r186579, the code in stmt.c would remove such case labels before any > of the RTL expanders got to see them. After my patch, the gimplifier > removed those out-of-range labels, but forwprop re-introduces them > and, en passant, makes the type of the switch index expression > different from the types of the case label values. > > This patch adds splits out the case label preprocessing code in > gimplify.c to a new function, and makes forwprop use it to update the > switch label values if it changes the switch index type. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk? Ok. Thanks, Richard. > Ciao! > Steven
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
Arno, The ChangeLog: Revert commit r184558 as breaking Ada runtime. The pseudo reloc feature works only when linking against DLL. Remove this pacth as it install the import libraries for the shared Ada runtime. This breaks any Ada program using the Ada shared runtime. With this ChangeLog just revert commit r184558 from FSF tree. For the record, this is the culprit: << commit 7ef88902afa64e783e9b612bf423fd9d12c668ff Author: davek Date: Fri Feb 24 16:17:01 2012 + libada/ChangeLog: * Makefile.in (bindir): Import from autoconf and pass down to submake. gcc/ada/ChangeLog: * gcc-interface/Makefile.in (WIN_SO_PREFIX [windows targets]): New Windows-specific make variable. (WIN_SO_INSTALL_DIR [windows targets]): Likewise. (install-gnatlib): Respect the above during installation when set, and also install any windows import library that has been built. (gnatlib-shared-win32): Use WIN_SO_PREFIX to name output DLL and also build a corresponding import library. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@184558 138bc75d-0d04-0410-96 >> Thanks. -- Pascal Obry -- gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Re: [PATCH RFC] Warn when optimization flag is given without -O
On Wed, May 2, 2012 at 12:03 PM, Alexander Monakov wrote: > > > On Wed, 2 May 2012, Richard Guenther wrote: > >> That's surely too coarse - you will warn about options that _will_ >> have an effect. >> There is currently no easy way to glob all affected options. > > Yeah, that's unfortunate. Do we want to have a separate flag > (CL_OPTIMIZATION_O0) to mark such options? Apropos, following is a list of > options that affect the list of produced dump files at O0. If someone knows > an option that affects compilation at O0, but is not a part of this list, > please let me know. > > -fbranch-probabilities > -fbranch-target-load-optimize > -fcombine-stack-adjustments > -fexceptions > -fhandle-exceptions > -fschedule-insns > -fsplit-wide-types > -fvar-tracking-assignments > -fvar-tracking-assignments-toggle > >> I don't think we want to warn about -O2 -ftree-pre -O0 either, nor > > Huh, I don't see why. Please explain? Because I routinely append -O0 to an existing command-line to disable optimization. I don't want to be spammed with unconditional warnings for this (btw, I think it should be a note(), not a warning). >> about -fno-tree-pre. > > Yeah, that's an oversight in the patch, should be easy to fix. > >> Overall I would expect people to have noticed that with -O0 these options >> have >> no effect when they've gone all the way to figure out the separate >> optimization >> options, no? > > At the moment people have two easy ways to find the list of optimization > options (-fverbose-asm and --help=optimizers), but O0 issue is mentioned > once not-quite-prominently in the manual and also in the FAQ in the wiki. > In my opinion, the amount of times I've seen this issue come up warrants > some effort on making it more visible (thus, a warning). So maybe prominently say that in the output of --help=optimizers (-fverbose-asm isn't to be found easily anyway). Thus, at the end of --help-optimizers print "Note: without any -On option, excluding -O0, most options do not have any effect" Richard. > Thanks > Alexander
Re: [PATCH] Don't ignore compute_all_dependences failures in phiopt (PR tree-optimization/53163)
On Wed, May 2, 2012 at 12:04 PM, Jakub Jelinek wrote:
> On Wed, May 02, 2012 at 11:24:13AM +0200, Richard Guenther wrote:
>> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
>> > ok for trunk/4.7?
>>
>> Ok.
>
> Thanks.
>
>> > BTW, tree-ssa-loop-prefetch.c seems to have the same problem, but no idea
>> > how that should be handled in there...
>>
>> I think it handles it fine by treating the chrec_dont_know DDR
>> properly? I suppose
>> failing would be an option, too, by returning a bool from
>> determine_loop_nest_reuse
>> and adjusting its single caller.
>
> IMHO it will just segfault (I don't have a testcase though).
>
> compute_all_dependences (datarefs, &dependences, vloops, true);
>
> FOR_EACH_VEC_ELT (ddr_p, dependences, i, dep)
> {
> if (DDR_ARE_DEPENDENT (dep) == chrec_known)
> continue;
>
> ref = (struct mem_ref *) DDR_A (dep)->aux;
> refb = (struct mem_ref *) DDR_B (dep)->aux;
>
> if (DDR_ARE_DEPENDENT (dep) == chrec_dont_know
> || DDR_NUM_DIST_VECTS (dep) == 0)
> {
> /* If the dependence cannot be analyzed, assume that there might
> * be
> a reuse. */
> dist = 0;
>
> ref->independent_p = false;
> refb->independent_p = false;
> }
>
> If compute_all_dependences above fails (returns false), then dependences
> vector will contain just single chrec_dont_know element, but with DDR_A
> (dep) == DDR_B (dep) == NULL. So the above will try to dereference both and
> ICE before checking chrec_dont_know (and even if it wouldn't, there is
> nothing to mark independent_p = false - supposedly everything should be
> no longer independent_p).
Hm, indeed. Mind fixing it the way I suggested?
Thanks,
Richard.
> Jakub
Re: Optimize calls to functions that return one of their arguments
On 05/02/2012 11:10 AM, Richard Guenther wrote: On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidt wrote: This patch allows us to recognize that even if the argument to memcpy lives across the call, we can allocate it to a call-used register by reusing the return value of the function. Heh, interesting idea. I suppose you chose memcpy/memmove because the middle-end emits those for block moves? Customer request actually. It just occurred to me that I could add strcpy as well. I see you've gone all the way generalizing support for this instead of a special hack (an RTL flag on the call, directly set by the expander?) for this case? The RTL flag wouldn't allow us to say which argument register is returned. I think the SET representation works reasonably well. I've chickened out at adding fnspec annotations to builtins because of the explosion of various strings that would need ;) That said, I like it but will leave the RTL / IRA parts to someone else to look at. Ok, will wait for that. Bernd
[PATCH] [i386] fma3 instruction generation for 'march=native' in AMD processors
For AMD architectures with both fma3 and fma4 instructions' support, GCC
generates fma4 by default. Instead, we like to generate fma3 instruction. Below
patch enables the fma3 instruction generation for "-march=native".
Ok for trunk?
Index: gcc/config/i386/driver-i386.c
===
--- gcc/config/i386/driver-i386.c (revision 186897)
+++ gcc/config/i386/driver-i386.c (working copy)
@@ -472,6 +472,10 @@
has_abm = ecx & bit_ABM;
has_lwp = ecx & bit_LWP;
has_fma4 = ecx & bit_FMA4;
+ if (((vendor == SIG_AMD)) && (has_fma4) && (has_fma))
+{
+has_fma4 = 0;
+}
has_xop = ecx & bit_XOP;
has_tbm = ecx & bit_TBM;
has_lzcnt = ecx & bit_LZCNT;
Regards
Ganesh
Re: [PATCH] Make sizetypes no longer sign-extending
On Fri, 27 Apr 2012, Eric Botcazou wrote: > > Ah, and all ACATS fails and > > > > -FAIL: gnat.dg/loop_optimization3.adb (test for excess errors) > > -FAIL: gnat.dg/loop_optimization3.adb execution test > > -FAIL: gnat.dg/test_8bitlong_overflow.adb (test for excess errors) > > -FAIL: gnat.dg/test_8bitlong_overflow.adb execution test > > > > are fixed by for example > > > > [...] > > > > thus are because array TYPE_DOMAIN is built using unsigned sizetype > > but these Ada testcases have array domains which really need signed > > types. The above is of course a hack, but one that otherwise survives > > bootstrap / test of all languages. > > Kind of a miracle if you ask me, but probably a reasonable way out for Ada. > Thanks a lot for devising it. > > > Thus, we arrive at the following Ada regression status if the patch series > > is applied (plus the above incremental patch): > > > > === acats tests === > > > > === acats Summary === > > # of expected passes2320 > > # of unexpected failures0 > > Native configuration is x86_64-unknown-linux-gnu > > > > === gnat tests === > > > > > > Running target unix/ > > FAIL: gnat.dg/array11.adb (test for warnings, line 12) > > FAIL: gnat.dg/object_overflow.adb (test for warnings, line 8) > > FAIL: gnat.dg/renaming5.adb scan-tree-dump-times optimized "goto" 2 > > FAIL: gnat.dg/return3.adb scan-assembler loc 1 6 > > > > === gnat Summary for unix/ === > > > > # of expected passes1093 > > # of unexpected failures4 > > # of expected failures 13 > > # of unsupported tests 2 > > > > Running target unix//-m32 > > FAIL: gnat.dg/array11.adb (test for warnings, line 12) > > FAIL: gnat.dg/object_overflow.adb (test for warnings, line 8) > > FAIL: gnat.dg/renaming5.adb scan-tree-dump-times optimized "goto" 2 > > FAIL: gnat.dg/return3.adb scan-assembler loc 1 6 > > > > === gnat Summary for unix//-m32 === > > > > # of expected passes1093 > > # of unexpected failures4 > > # of expected failures 13 > > # of unsupported tests 2 > > > > === gnat Summary === > > > > # of expected passes2186 > > # of unexpected failures8 > > # of expected failures 26 > > # of unsupported tests 4 > > > > > > Which I consider reasonable? > > Sure, no opposition by me to applying the whole set of patches. Done now. Thanks, Richard.
Re: [PATCH] [i386] fma3 instruction generation for 'march=native' in AMD processors
On Wed, May 02, 2012 at 11:12:33AM +, Gopalasubramanian, Ganesh wrote:
> For AMD architectures with both fma3 and fma4 instructions' support, GCC
> generates fma4 by default. Instead, we like to generate fma3 instruction.
> Below patch enables the fma3 instruction generation for "-march=native".
>
> Ok for trunk?
You haven't provided ChangeLog entry.
> Index: gcc/config/i386/driver-i386.c
> ===
> --- gcc/config/i386/driver-i386.c (revision 186897)
> +++ gcc/config/i386/driver-i386.c (working copy)
> @@ -472,6 +472,10 @@
>has_abm = ecx & bit_ABM;
>has_lwp = ecx & bit_LWP;
>has_fma4 = ecx & bit_FMA4;
> + if (((vendor == SIG_AMD)) && (has_fma4) && (has_fma))
> +{
> +has_fma4 = 0;
> +}
And the formatting of this is wrong, 4 unnecessary pairs of (),
one unnecessary {} pair, bad indentation of the has_fma4 = 0;
assignment (should use a tab).
Jakub
Re: [RFH / Patch] PR 51222
On 05/02/2012 05:01 AM, Paolo Carlini wrote:
Anyway, the attached appear to also pass the testsuite, I could test
it more completely tomorrow. If the FIELD_DECL bits seem safe to
have... ;)
Now fully booted and tested.
I also booted and tested a variant, attached, which changes
finish_static_assert to also use instantiation_dependent_expression_p
and also passes testing: nice, between front-end and library we stress
the new function quite a bit more.
Paolo.
/
Index: cp/pt.c
===
--- cp/pt.c (revision 187039)
+++ cp/pt.c (working copy)
@@ -145,8 +145,8 @@ static tree convert_nontype_argument_function (tre
static tree convert_nontype_argument (tree, tree, tsubst_flags_t);
static tree convert_template_argument (tree, tree, tree,
tsubst_flags_t, int, tree);
-static int for_each_template_parm (tree, tree_fn_t, void*,
- struct pointer_set_t*, bool);
+static int walk_template_parms (tree, tree_fn_t, void*,
+ struct pointer_set_t*, bool, bool);
static tree expand_template_argument_pack (tree);
static tree build_template_parm_index (int, int, int, int, tree, tree);
static bool inline_needs_template_parms (tree);
@@ -185,7 +185,7 @@ static int coerce_template_template_parms (tree, t
static bool template_template_parm_bindings_ok_p (tree, tree);
static int template_args_equal (tree, tree);
static void tsubst_default_arguments (tree);
-static tree for_each_template_parm_r (tree *, int *, void *);
+static tree walk_template_parms_r (tree *, int *, void *);
static tree copy_default_args_to_explicit_spec_1 (tree, tree);
static void copy_default_args_to_explicit_spec (tree);
static int invalid_nontype_parm_type_p (tree, tsubst_flags_t);
@@ -4276,8 +4276,8 @@ mark_template_parm (tree t, void* data)
tpd->arg_uses_template_parms[tpd->current_arg] = 1;
}
- /* Return zero so that for_each_template_parm will continue the
- traversal of the tree; we want to mark *every* template parm. */
+ /* Return zero so that walk_template_parms will continue the traversal
+ of the tree; we want to mark *every* template parm. */
return 0;
}
@@ -4344,11 +4344,12 @@ process_partial_specialization (tree decl)
for (i = 0; i < nargs; ++i)
{
tpd.current_arg = i;
- for_each_template_parm (TREE_VEC_ELT (inner_args, i),
- &mark_template_parm,
- &tpd,
- NULL,
- /*include_nondeduced_p=*/false);
+ walk_template_parms (TREE_VEC_ELT (inner_args, i),
+ &mark_template_parm,
+ &tpd,
+ NULL,
+ /*check_types=*/false,
+ /*include_nondeduced_p=*/false);
}
for (i = 0; i < ntparms; ++i)
if (tpd.parms[i] == 0)
@@ -4481,11 +4482,12 @@ process_partial_specialization (tree decl)
tpd2.current_arg = i;
tpd2.arg_uses_template_parms[i] = 0;
memset (tpd2.parms, 0, sizeof (int) * nargs);
- for_each_template_parm (type,
- &mark_template_parm,
- &tpd2,
- NULL,
- /*include_nondeduced_p=*/false);
+ walk_template_parms (type,
+ &mark_template_parm,
+ &tpd2,
+ NULL,
+ /*check_types=*/false,
+ /*include_nondeduced_p=*/false);
if (tpd2.arg_uses_template_parms [i])
{
@@ -4755,7 +4757,7 @@ check_default_tmpl_args (tree decl, tree parms, in
}
/* Worker for push_template_decl_real, called via
- for_each_template_parm. DATA is really an int, indicating the
+ walk_template_parms. DATA is really an int, indicating the
level of the parameters we are interested in. If T is a template
parameter of that level, return nonzero. */
@@ -7750,26 +7752,34 @@ struct pair_fn_data
{
tree_fn_t fn;
void *data;
+ bool check_types;
/* True when we should also visit template parameters that occur in
non-deduced contexts. */
bool include_nondeduced_p;
struct pointer_set_t *visited;
};
-/* Called from for_each_template_parm via walk_tree. */
+/* Called from walk_template_parms via walk_tree. */
static tree
-for_each_template_parm_r (tree *tp, int *walk_subtrees, void *d)
+walk_template_parms_r (tree *tp, int *walk_subtrees, void *d)
{
tree t = *tp;
struct pair_fn_data *pfd = (struct pair_fn_data *) d;
tree_fn_t fn = pfd->fn;
void *data = pfd->data;
+ /* If
Re: [patch] More thorough checking in reg_fits_class_p
On 30/04/12 16:19, Richard Sandiford wrote:
Richard Earnshaw writes:
On 30/04/12 15:39, Richard Sandiford wrote:
Richard Earnshaw writes:
On 30/04/12 15:07, Richard Sandiford wrote:
Richard Earnshaw writes:
On 26/04/12 14:20, Jim MacArthur wrote:
The current code in reg_fits_class_p appears to be incorrect; since
offset may be negative, it's necessary to check both ends of the range
otherwise an array overrun or underrun may occur when calling
in_hard_reg_set_p. in_hard_reg_set_p should also be checked for each
register in the range of regno .. regno+offset.
A negative offset can occur on a big-endian target. For example, on
AArch64, subreg_regno_offset (0, DImode, 0, TImode) returns -1.
We discovered this problem while developing unrelated code for
big-endian support in the AArch64 back end.
I've tested this with an x86 bootstrap which shows no errors, and with
our own AArch64 back end.
Ok for trunk?
gcc/Changelog entry:
2012-04-26 Jim MacArthur
* recog.c (reg_fits_class_p): Check every register between regno and
regno+offset is in the hard register set.
OK.
R.
reg-fits-class-9
diff --git a/gcc/recog.c b/gcc/recog.c
index 8fb96a0..825bfb1 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -2759,14 +2759,28 @@ bool
reg_fits_class_p (const_rtx operand, reg_class_t cl, int offset,
enum machine_mode mode)
{
- int regno = REGNO (operand);
+ unsigned int regno = REGNO (operand);
if (cl == NO_REGS)
return false;
- return (HARD_REGISTER_NUM_P (regno)
- && in_hard_reg_set_p (reg_class_contents[(int) cl],
- mode, regno + offset));
+ /* We should not assume all registers in the range regno to regno + offset
are
+ valid just because each end of the range is. */
+ if (HARD_REGISTER_NUM_P (regno)&& HARD_REGISTER_NUM_P (regno + offset))
+{
+ unsigned int i;
+
+ unsigned int start = MIN (regno, regno + offset);
+ unsigned int end = MAX (regno, regno + offset);
+ for (i = start; i<= end; i++)
+ {
+ if (!in_hard_reg_set_p (reg_class_contents[(int) cl],
+ mode, i))
+ return false;
+ }
This doesn't look right to me. We should still only need to check
in_hard_reg_set_p for one register number. I'd have expected
something like:
return (HARD_REGISTER_NUM_P (regno)
&& HARD_REGISTER_NUM_P (regno + offset)
&& in_hard_reg_set_p (reg_class_contents[(int) cl],
mode, regno + offset));
instead.
Richard
There's no guarantee that all registers in a set are contiguous; ARM for
example doesn't make that guarantee, since SP is not a GP register, but
R12 and R14 are.
Sorry, I don't follow. My point was that in_hard_reg_set_p (C, M, R1)
tests whether every register required to store a value of mode M starting
at R1 fits in C. Which is what we want to know.
Whether the intermediate registers (between regno and regno + offset)
are even valid for MODE shouldn't matter. I don't think it makes
conceptual sense to call:
if (!in_hard_reg_set_p (reg_class_contents[(int) cl],
mode, i))
for regno< i< regno + offset (or regno + offset< i< regno),
because we're not trying to construct a value of mode MODE
in that register.
Richard
You're right, of course. I'd missed that in my initial review; and
hence my follow-up suggestion. It's not particularly interesting
whether or not HARD_REGISTER_NUM_P (REGNO (operand)) is true, only
whether REGNO(operand) + offset ... REGNO(operand) + offset +
NUM_REGS(mode) -1 is.
The problem is that the function currently accepts pseudo registers.
We wouldn't want FIRST_PSEUDO_REGISTER to be accidentally associated
with FIRST_PSUEDO_REGISTER-1, however unlikely that combination of
arguments might be in practice. I think the HARD_REGISTER_NUM_P check
is needed for both regno and regno + offset.
I agree that we should protect against overrun in in_hard_reg_set,
but I think that check logically belongs there. Most targets happen
to be OK because FIRST_PSEUDO_REGISTER isn't divisible by 32,
so the class HARD_REG_SETs always have a terminating zero bit.
There are a couple of exceptions though, such as alpha and lm32.
So one fix would be to require HARD_REG_SET to have an entry
for FIRST_PSEUDO_REGISTER, which wouldn't affect most targets.
Another would be to have an explicit range check in in_hard_reg_set_p
and friends.
Richard
Thanks for all your comments. I've made a new version which checks all
three cases (regno, regno+offset, end_hard_regno (regno+offset, M) )
with HARD_REGISTER_NUM_P but returns to just checking regno + offset
with in_hard_reg_set_p. How does this look?
New Changelog text:
2012-05-02 Jim MacArthur
* recog.c (reg_fits_class_p): Check both regno and regno + offset are
hard registers.
diff --git a/gcc/recog.c b/gcc/recog.c
index 8fb96a0..a416e06 100644
--- a/gcc/recog.c
+++ b
Re: [PATCH] Improve COND_EXPR expansion
On Mon, 2012-04-30 at 20:22 -0700, Andrew Pinski wrote: > Hi, > This patch improves the expansion of COND_EXPR into RTL, directly > using conditional moves. > I had to fix a bug in the x86 backend where emit_conditional_move > could cause a crash as we had a comparison mode of DImode which is not > handled by the 32bit part. can_conditionally_move_p return true as we > had an SImode for the other operands. > Note other targets might need a similar fix as x86 had but I could not > test those targets and this is really the first time where > emit_conditional_move is being called with different modes for the > comparison and the other operands mode and the comparison mode is not > of the CC class. Hi Andrew, I verified your patch on powerpc64-unknown-linux-gnu. There were no new testcase regressions, and SPEC cpu2006 built ok with your changes. Hope this helps! Bill > > The main reasoning to do this conversion early rather than wait for > ifconv as the resulting code is slightly better. Also the compiler is > slightly faster. > > OK? Bootstrapped and tested on both mips64-linux-gnu (where it was > originally written for) and x86_64-linux-gnu. > > Thanks, > Andrew Pinski > > ChangeLog: > * expr.c (convert_tree_comp_to_rtx): New function. > (expand_expr_real_2): Try using conditional moves for COND_EXPRs if they > exist. > * config/i386/i386.c (ix86_expand_int_movcc): Disallow comparison > modes of DImode for 32bits and TImode.
Re: [PATCH] Fix overzealous DSE on sparc
this looks ok to me, but I am going to defer this to richard for final
acceptance. his contribution to this pass was his deep knowledge of
rtl so that we could get the scanning correct and this is clearly in
that domain. He may have some trick that does not throw all of the
baby out with the bath water.
Kenny
On 05/02/2012 04:25 AM, David Miller wrote:
On targets such as sparc, where ARG_POINTER_REGNUM ==
FRAME_POINTER_REGNUM, some of the invariants currently built into DSE
simply do not hold.
Unlike how DSE assumes, we will in fact see stores to frame pointer
relative addresses for setting up outgoing arguments to a CALL.
The result is that DSE can eliminate stores that setup those
arguments.
Two test cases and a DSE debugging dump for one of them can be found
at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
Richard and Kenneth, can you take a look at this? The patch is
against the 4.7 branch, which is where I've been tracking this down.
I'm currently running it through a regstrap and a glibc build (the
latter of which is where I originally saw this problem)
Thanks.
2012-05-01 David S. Miller
PR target/53684
* dse.c (scan_insn): When the frame pointer is used as the
argument pointer, mark non-const calls as frame_read.
--- gcc/dse.c~ 2012-05-01 20:27:48.163611555 -0700
+++ gcc/dse.c 2012-05-02 01:03:19.450719154 -0700
@@ -2646,10 +2646,17 @@ scan_insn (bb_info_t bb_info, rtx insn)
}
else
- /* Every other call, including pure functions, may read any memory
- that is not relative to the frame. */
-add_non_frame_wild_read (bb_info);
-
+ {
+ /* Every other call, including pure functions, may read any memory
+that is not relative to the frame. */
+ add_non_frame_wild_read (bb_info);
+#if FRAME_POINTER_REGNUM == ARG_POINTER_REGNUM
+ /* If the target uses the frame pointer as the argument
+pointer, then we will encounter frame relative stores
+that setup outgoing arguments to a function. */
+ insn_info->frame_read = true;
+#endif
+ }
return;
}
Re: [PATCH] libatomic, v2
On 05/01/2012 05:53 PM, Richard Henderson wrote: > On 04/27/2012 12:26 PM, Richard Henderson wrote: >> I think the library is ready for merge back to mainline, but >> I will wait until at least Monday for feedback and proximity >> to my desk to deal with potential fallout. > > Now committed. With that patch the bootstrap on my daily build system fails (s390x-ibm-linux-gnu). It has autoconf 2.65 installed which should not hurt since the libatomic configure file is already there. But due to the version check the compilation stops with: configure.ac:26: error: Please use exactly Autoconf 2.64 instead of 2.65. ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:26: the top level autom4te: m4 failed with exit status: 1 aclocal-1.11: autom4te failed with exit status: 1 make[2]: *** [/home/andreas/git/gcc-head/libatomic/aclocal.m4] Error 1 make[2]: Leaving directory `/home/andreas/git/gcc-head-build/s390x-ibm-linux-gnu/libatomic' make[1]: *** [all-target-libatomic] Error 2 make[1]: *** Waiting for unfinished jobs -Andreas-
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
OK, revision 184558 now reverted. Arno -- Index: gcc/ada/ChangeLog === --- gcc/ada/ChangeLog (revision 187037) +++ gcc/ada/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2012-05-02 Pascal Obry + + Revert + 2012-02-24 Dave Korn + 2012-04-30 Jan Hubicka * gcc-interface/utils.c (rest_of_subprog_body_compilation): Update @@ -1599,7 +1604,7 @@ 2012-02-22 Hristian Kirtchev - * exp_ch7.adb (Create_Finalizer): Suppress elaboration checks on + * exp_ch7.adb (Create_Finalizer): Suppress elaboration checks on stack-related finalizers. 2012-02-22 Ed Schonberg Index: gcc/ada/gcc-interface/Makefile.in === --- gcc/ada/gcc-interface/Makefile.in (revision 187037) +++ gcc/ada/gcc-interface/Makefile.in (working copy) @@ -1547,19 +1547,16 @@ ifeq ($(strip $(filter-out cygwin% mingw # the Cygwin port has always been a CygMing frankenhybrid and it is # a long-term project to disentangle them. ifeq ($(strip $(filter-out cygwin%,$(osys))),) -WIN_SO_PREFIX=cyg LIBGNAT_TARGET_PAIRS = \ s-memory.adb + + Revert + 2012-02-24 Dave Korn + 2012-02-24 Dave Korn * Makefile.in (bindir): Import from autoconf and pass down to submake. @@ -97,7 +102,7 @@ 2008-09-21 Laurent Guerby Paolo Bonzini - + PR ada/5911 * Makefile.in (all, install, mostlyclean, clean, distclean): Add multilib handling. @@ -105,7 +110,7 @@ * configure: Regenerate. 2008-08-29 Laurent Guerby - + * Makefile.in (FLAGS_TO_PASS): renamed to LIBADA_FLAGS_TO_PASS to avoid conflicts. Factor more flags to pass. (libsubdir): New variable. @@ -114,7 +119,7 @@ 2008-08-28 Laurent Guerby * configure: Regenerate. - + 2008-08-06 Thomas Quinot * Makefile.in: generate s-oscons.ads again, previous change was Index: libada/Makefile.in === --- libada/Makefile.in (revision 187037) +++ libada/Makefile.in (working copy) @@ -33,7 +33,6 @@ MULTICLEAN = true SHELL = @SHELL@ srcdir = @srcdir@ libdir = @libdir@ -bindir = @bindir@ build = @build@ target = @target@ prefix = @prefix@ @@ -84,7 +83,6 @@ LIBADA_FLAGS_TO_PASS = \ "TRACE=$(TRACE)" \ "MULTISUBDIR=$(MULTISUBDIR)" \ "libsubdir=$(libsubdir)" \ -"bindir=$(bindir)" \ "objext=$(objext)" \ "prefix=$(prefix)" \ "exeext=.exeext.should.not.be.used " \
Re: [patch] PR53153
On Wed, May 2, 2012 at 12:14 PM, Richard Guenther wrote: > On Wed, May 2, 2012 at 10:32 AM, Steven Bosscher > wrote: >> Hello, >> >> The attached patch fixes PR53153. >> >> The problem is that tree-ssa-forwprop.c propagates away a cast, but >> leaves out-of-range case labels in the switch. Before my patch for >> r186579, the code in stmt.c would remove such case labels before any >> of the RTL expanders got to see them. After my patch, the gimplifier >> removed those out-of-range labels, but forwprop re-introduces them >> and, en passant, makes the type of the switch index expression >> different from the types of the case label values. >> >> This patch adds splits out the case label preprocessing code in >> gimplify.c to a new function, and makes forwprop use it to update the >> switch label values if it changes the switch index type. >> >> Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk? > > Ok. > > Thanks, > Richard. Thanks, commited as r187048 with one mistake fixed that I noticed while reviewing my own patch: diff -u tree-ssa-forwprop.c tree-ssa-forwprop.c --- tree-ssa-forwprop.c (working copy) +++ tree-ssa-forwprop.c (working copy) @@ -1387,6 +1387,8 @@ } BITMAP_FREE (target_blocks); } + + VEC_free (tree, heap, labels); } /* STMT is a SWITCH_EXPR for which we attempt to find equivalent forms of
Re: [patch] More thorough checking in reg_fits_class_p
Jim MacArthur writes: > New Changelog text: > > 2012-05-02 Jim MacArthur > * recog.c (reg_fits_class_p): Check both regno and regno + offset are > hard registers. Thanks. I still think the final: > + && HARD_REGISTER_NUM_P (end_hard_regno (regno + offset, mode)) check belongs in in_hard_reg_set_p, since most callers don't (and IMO shouldn't need to) check this. The idea behind adding these functions was to commonise various bits of code that were doing the same checks in slightly different ways. Requiring each caller to check the end register would go against that to some extent. E.g. the code could be: end_regno = end_hard_regno (mode, regno); if (!HARD_REGISTER_NUM_P (end_regno)) return false; while (++regno < end_regno) if (!TEST_HARD_REG_BIT (regs, regno)) return false; Or alternatively we could change hard-reg-set.h so that HARD_REG_SET is big enough to store a bit for FIRST_PSEUDO_REGISTER. I don't mind which, but others might. Looks good otherwise. And for the record, I can't approve this anyway. :-) Richard
Re: [PATCH] libatomic, v2
On 05/02/2012 05:48 AM, Andreas Krebbel wrote: configure.ac:26: error: Please use exactly Autoconf 2.64 instead of 2.65. ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:26: the top level autom4te: m4 failed with exit status: 1 aclocal-1.11: autom4te failed with exit status: 1 This is of course not unique to libatomic. Use ./contrib/gcc_update. r~
Re: libgo patch committed: Fix build on MIPS GNU/Linux
Andrew Pinski writes: > n32 failures: > > --- FAIL: runtime_test.TestGcSys (0.56 seconds) > mfinal_test.go:35: used 4718592 extra bytes > mfinal_test.go:37: using too much memory: 4718592 bytes > FAIL > FAIL: runtime > /home/apinski/src/gcc-fsf/local/gcc/libgo/testsuite/gotest: line 448: > gotest-timeout: No such file or directory > > panic: test timed out > FAIL: net/http > .. > --- FAIL: template.TestExecute (0.29 seconds) > template.go:531: chained method: unexpected execute error: > template: chained method:1: nil pointer evaluating > *template.U.TrueFalse > template.go:531: chained method on variable: unexpected > execute error: template: chained method on variable:1: nil pointer > evaluating *template.U.TrueFalse > template.go:541: range count: expected > "[0]a[1]b[2]c[3]d[4]e" > got > "" > FAIL > FAIL: text/template > > n64: > panic: test timed out > FAIL: net/http > /home/apinski/src/gcc-fsf/local/gcc/libgo/testsuite/gotest: line 448: > gotest-timeout: No such file or directory Thanks. Unfortunately I can't see what is going wrong. Ian
[patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
configuration. The reason is that gcc -print-multi-directory doesn't print
anything for the non-default, and gcc -print-multi-lib only prints `.' (and then
not building the runtime libs for the non-default). The reason is that
set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
linux-elf.h), but not configure_default_options in configargs.h. This proposed
patch updates MULTILIB_DEFAULTS depending on the configure options. An
alternative approach would be to update set_multilib_dir and print_multilib_info
to lookup configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what change
did cause the build failure.
I didn't check if other targets need an update as well.
Ok for the trunk?
Matthias
# DP: Set MULTILIB_DEFAULTS for ARM multilib builds
* config.gcc (arm*-*-*): Set TARGET_CONFIGURED_FLOAT_ABI and
TARGET_CONFIGURED_THUMB_MODE when configured --with-float and
--with-mode.
* config/arm/linux-eabi.h (MULTILIB_DEFAULTS): Set depending
on TARGET_CONFIGURED_FLOAT_ABI, TARGET_CONFIGURED_THUMB_MODE and
TARGET_BIG_ENDIAN_DEFAULT.
Index: b/src/gcc/config.gcc
===
--- a/src/gcc/config.gcc2012-05-02 10:24:10.585842104 +
+++ b/src/gcc/config.gcc2012-05-02 10:26:12.509846641 +
@@ -3047,10 +3047,18 @@
esac
case "$with_float" in
- "" \
- | soft | hard | softfp)
+ "")
# OK
;;
+ soft)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=0"
+ ;;
+ softfp)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=1"
+ ;;
+ hard)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=2"
+ ;;
*)
echo "Unknown floating point type used in
--with-float=$with_float" 1>&2
exit 1
@@ -3094,6 +3102,9 @@
"" \
| arm | thumb )
#OK
+ if test "$with_mode" = thumb; then
+ tm_defines="${tm_defines}
TARGET_CONFIGURED_THUMB_MODE=1"
+ fi
;;
*)
echo "Unknown mode used in --with-mode=$with_mode"
Index: b/src/gcc/config/arm/linux-eabi.h
===
--- a/src/gcc/config/arm/linux-eabi.h 2012-05-02 10:24:10.585842104 +
+++ b/src/gcc/config/arm/linux-eabi.h 2012-05-02 10:26:55.141848227 +
@@ -34,7 +34,21 @@
/* We default to a soft-float ABI so that binaries can run on all
target hardware. */
#undef TARGET_DEFAULT_FLOAT_ABI
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=hard"
+#elif TARGET_CONFIGURED_FLOAT_ABI == 1
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFTFP
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=softfp"
+#else
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=soft"
+#endif
+#else
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=soft"
+#endif
/* We default to the "aapcs-linux" ABI so that enums are int-sized by
default. */
@@ -68,6 +82,28 @@
"%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
%{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
+/* Set the multilib defaults according the configuration, needed to
+ let gcc -print-multi-dir do the right thing. */
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define MULTILIB_DEFAULT_ENDIAN "mbig-endian"
+#else
+#define MULTILIB_DEFAULT_ENDIAN "mlittle-endian"
+#endif
+
+#ifndef TARGET_CONFIGURED_THUMB_MODE
+#define MULTILIB_DEFAULT_MODE "marm"
+#elif TARGET_CONFIGURED_THUMB_MODE == 1
+#define MULTILIB_DEFAULT_MODE "mthumb"
+#else
+#define MULTILIB_DEFAULT_MODE "marm"
+#endif
+
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+ { MULTILIB_DEFAULT_MODE, MULTILIB_DEFAULT_ENDIAN, \
+ MULTILIB_DEFAULT_FLOAT_ABI, "mno-thumb-interwork" }
+
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
#undef LINK_SPEC
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
> Hi H.J,
>
> Done now. Patch attached.
>
> Thanks,
> -Sri.
>
> On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
>> On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam wrote:
>>> Hi,
>>>
>>> New patch attached, updated test case and fixed bugs related to
>>> __PRETTY_FUNCTION_.
>>>
>>> Patch also available for review here: http://codereview.appspot.com/5752064
>>
>> @@ -0,0 +1,39 @@
>> +/* Simple test case to check if Multiversioning works. */
>> +/* { dg-do run } */
>> +/* { dg-options "-O2 -fPIC" } */
>> +
>> +#include
>> +
>> +int foo ();
>> +int foo () __attribute__ ((target("arch=corei7,sse4.2,popcnt")));
>> +/* The target operands in this declaration and the definition are
>> re-ordered.
>> + This should still work. */
>> +int foo () __attribute__ ((target("ssse3,avx2")));
>> +
>> +int (*p)() = &foo;
>> +int main ()
>> +{
>> + return foo () + (*p)();
>> +}
>> +
>> +int foo ()
>> +{
>> + return 0;
>> +}
>> +
>> +int __attribute__ ((target("arch=corei7,sse4.2,popcnt")))
>> +foo ()
>> +{
>> + assert (__builtin_cpu_is ("corei7")
>> + && __builtin_cpu_supports ("sse4.2")
>> + && __builtin_cpu_supports ("popcnt"));
>> + return 0;
>> +}
>> +
>> +int __attribute__ ((target("avx2,ssse3")))
>> +foo ()
>> +{
>> + assert (__builtin_cpu_supports ("avx2")
>> + && __builtin_cpu_supports ("ssse3"));
>> + return 0;
>> +}
>>
>> This test will pass if
>>
>> int foo ()
>> {
>> return 0;
>> }
>>
>> is selected on processors with AVX. The run-time test should
>> check that the right function is selected on the target processor,
>> not the selected function matches the target attribute. You can
>> do it by returning different values for each foo and call cpuid
>> to check if the right foo is selected.
>>
>> You should add a testcase for __builtin_cpu_supports to check
>> all valid arguments.
>>
>> --
>> H.J.
2 questions:
1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
foo for AVX and SSE3, on AVX processors, which foo will be
selected?
2. I don't see any tests for __builtin_cpu_supports ("XXX")
nor __builtin_cpu_is ("XXX"). I think you need tests for
them.
--
H.J.
Re: [patch] More thorough checking in reg_fits_class_p
On 02/05/12 14:00, Richard Sandiford wrote: > Jim MacArthur writes: >> New Changelog text: >> >> 2012-05-02 Jim MacArthur >> * recog.c (reg_fits_class_p): Check both regno and regno + offset are >> hard registers. > > Thanks. I still think the final: > >> + && HARD_REGISTER_NUM_P (end_hard_regno (regno + offset, mode)) > > check belongs in in_hard_reg_set_p, since most callers don't (and IMO > shouldn't need to) check this. The idea behind adding these functions > was to commonise various bits of code that were doing the same checks > in slightly different ways. Requiring each caller to check the end > register would go against that to some extent. > If you're going to do that (which is fine, BTW), I think in_hard_reg_set_p should gcc_assert() that regno is a valid hard reg. > E.g. the code could be: > > end_regno = end_hard_regno (mode, regno); > if (!HARD_REGISTER_NUM_P (end_regno)) > return false; > > while (++regno < end_regno) > if (!TEST_HARD_REG_BIT (regs, regno)) > return false; > > Or alternatively we could change hard-reg-set.h so that HARD_REG_SET > is big enough to store a bit for FIRST_PSEUDO_REGISTER. I don't mind > which, but others might. I'd prefer the test to be explicit. The buffer overrun check might be a tad more efficient in some cases, but someday someone will manage to find a way of directly going 2 regs beyond the end... > > Looks good otherwise. And for the record, I can't approve this anyway. :-) > > Richard >
Re: [PATCH] libatomic, v2
On 05/02/2012 03:14 PM, Richard Henderson wrote: > On 05/02/2012 05:48 AM, Andreas Krebbel wrote: >> configure.ac:26: error: Please use exactly Autoconf 2.64 instead of 2.65. >> ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... >> configure.ac:26: the top level >> autom4te: m4 failed with exit status: 1 >> aclocal-1.11: autom4te failed with exit status: 1 > > This is of course not unique to libatomic. Use ./contrib/gcc_update. Indeed. Sorry for not having a closer look first. -Andreas-
Re: [patch] More thorough checking in reg_fits_class_p
Richard Earnshaw writes: > On 02/05/12 14:00, Richard Sandiford wrote: >> Jim MacArthur writes: >>> New Changelog text: >>> >>> 2012-05-02 Jim MacArthur >>> * recog.c (reg_fits_class_p): Check both regno and regno + offset are >>> hard registers. >> >> Thanks. I still think the final: >> >>> + && HARD_REGISTER_NUM_P (end_hard_regno (regno + offset, mode)) >> >> check belongs in in_hard_reg_set_p, since most callers don't (and IMO >> shouldn't need to) check this. The idea behind adding these functions >> was to commonise various bits of code that were doing the same checks >> in slightly different ways. Requiring each caller to check the end >> register would go against that to some extent. >> > > If you're going to do that (which is fine, BTW), I think > in_hard_reg_set_p should gcc_assert() that regno is a valid hard reg. Sounds good. Richard
Re: [PATCH] Fix for PR51879 - Missed tail merging with non-const/pure calls
On 27/04/12 11:01, Richard Guenther wrote:
> I see you do not handle
> struct S { int i; };
> struct S foo (void);
> struct S bar (void)
> {
> struct S s1, s2;
> if (...)
>s = foo ();
> else
>s = foo ();
>
> because the calls have a LHS that is not an SSA name.
Indeed, the gvn patch handles this example conservatively, and
tree-tail-merge
fails to optimize this test-case:
...
struct S { int i; };
extern struct S foo (void);
extern int foo2 (void);
struct S s;
int bar (int c) {
int r;
if (c)
{
s = foo ();
r = foo2 ();
}
else
{
s = foo ();
r = foo2 ();
}
return r;
}
...
A todo.
bootstrapped and reg-tested on x86_64 (ada inclusive).
Is this patch ok, or is the todo required?
>>>
>>> No, you can followup with that.
>>>
Richard,
here is the follow-up patch, which adds value numbering of a call for which the
lhs is not an SSA_NAME.
The only thing I ended up using from the patch in
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01731.html was the idea of using
MODIFY_EXPR.
I don't include any handling of MODIFY_EXPR in create_component_ref_by_pieces_1
because I don't think it will trigger with PRE.
bootstrapped and reg-tested on x86_64.
Ok for trunk?
Thanks,
- Tom
2012-05-02 Tom de Vries
* tree-ssa-sccvn.c (copy_reference_ops_from_call)
(visit_reference_op_call): Handle case that lhs is not an SSA_NAME.
(visit_use): Call visit_reference_op_call for calls with lhs that is not
an SSA_NAME.
* gcc.dg/pr51879-16.c: New test.
* gcc.dg/pr51879-17.c: Same.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c (revision 186907)
+++ gcc/tree-ssa-sccvn.c (working copy)
@@ -942,6 +947,17 @@ copy_reference_ops_from_call (gimple cal
{
vn_reference_op_s temp;
unsigned i;
+ tree lhs = gimple_call_lhs (call);
+
+ if (lhs && TREE_CODE (lhs) != SSA_NAME)
+{
+ memset (&temp, 0, sizeof (temp));
+ temp.opcode = MODIFY_EXPR;
+ temp.type = TREE_TYPE (lhs);
+ temp.op0 = lhs;
+ temp.off = -1;
+ VEC_safe_push (vn_reference_op_s, heap, *result, &temp);
+}
/* Copy the type, opcode, function being called and static chain. */
memset (&temp, 0, sizeof (temp));
@@ -2624,6 +2641,9 @@ visit_reference_op_call (tree lhs, gimpl
tree vuse = gimple_vuse (stmt);
tree vdef = gimple_vdef (stmt);
+ if (lhs && TREE_CODE (lhs) != SSA_NAME)
+lhs = NULL_TREE;
+
vr1.vuse = vuse ? SSA_VAL (vuse) : NULL_TREE;
vr1.operands = valueize_shared_reference_ops_from_call (stmt);
vr1.type = gimple_expr_type (stmt);
@@ -3410,9 +3432,7 @@ visit_use (tree use)
/* If the call has side effects, subsequent calls won't have
the same incoming vuse, so it's save to assume
equality. */
- || gimple_has_side_effects (stmt))
- && ((lhs && TREE_CODE (lhs) == SSA_NAME)
- || (!lhs && gimple_vdef (stmt
+ || gimple_has_side_effects (stmt)))
{
changed = visit_reference_op_call (lhs, stmt);
}
Index: gcc/testsuite/gcc.dg/pr51879-16.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr51879-16.c (revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-pre" } */
+
+struct S {
+ int i;
+};
+
+extern struct S foo (void);
+extern int foo2 (void);
+
+struct S s;
+
+int bar (int c) {
+ int r;
+
+ if (c)
+{
+ s = foo ();
+ r = foo2 ();
+}
+ else
+{
+ s = foo ();
+ r = foo2 ();
+}
+
+ return r;
+}
+
+/* { dg-final { scan-tree-dump-times "foo \\(" 1 "pre"} } */
+/* { dg-final { scan-tree-dump-times "foo2 \\(" 1 "pre"} } */
+/* { dg-final { cleanup-tree-dump "pre" } } */
Index: gcc/testsuite/gcc.dg/pr51879-17.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr51879-17.c (revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-pre" } */
+
+struct S {
+ int i;
+};
+
+extern struct S foo (void);
+extern int foo2 (void);
+
+struct S s, s2;
+
+int bar (int c) {
+ int r;
+
+ if (c)
+{
+ s = foo ();
+ r = foo2 ();
+}
+ else
+{
+ s2 = foo ();
+ r = foo2 ();
+}
+
+ return r;
+}
+
+/* { dg-final { scan-tree-dump-times "foo \\(" 2 "pre"} } */
+/* { dg-final { scan-tree-dump-times "foo2 \\(" 2 "pre"} } */
+/* { dg-final { cleanup-tree-dump "pre" } } */
Spital nou de pediatrie
http://www.youtube.com/watch?feature=player_embedded&v=phjGxHn3uKU To unsubscribe please send email to unsubscr...@cc.psd-prahova.ro
Re: [patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
On 02/05/12 14:26, Matthias Klose wrote:
> I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
> configuration. The reason is that gcc -print-multi-directory doesn't print
> anything for the non-default, and gcc -print-multi-lib only prints `.' (and
> then
> not building the runtime libs for the non-default). The reason is that
> set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
> linux-elf.h), but not configure_default_options in configargs.h. This
> proposed
> patch updates MULTILIB_DEFAULTS depending on the configure options. An
> alternative approach would be to update set_multilib_dir and
> print_multilib_info
> to lookup configure_default_options in configargs.h as well.
>
> Note that this didn't fail to build in gcc-4.6, but I can't see yet what
> change
> did cause the build failure.
>
> I didn't check if other targets need an update as well.
>
> Ok for the trunk?
>
> Matthias
>
This patch doesn't appear to be based of FSF trunk...
> @@ -68,6 +82,28 @@
> "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
>
This pre-amble code has never existed in the FSF build.
Please ensure you are testing patches against the FSF sources, not some
custom variant.
R.
Re: [patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
On 02.05.2012 16:53, Richard Earnshaw wrote:
> On 02/05/12 14:26, Matthias Klose wrote:
>> I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
>> configuration. The reason is that gcc -print-multi-directory doesn't print
>> anything for the non-default, and gcc -print-multi-lib only prints `.' (and
>> then
>> not building the runtime libs for the non-default). The reason is that
>> set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
>> linux-elf.h), but not configure_default_options in configargs.h. This
>> proposed
>> patch updates MULTILIB_DEFAULTS depending on the configure options. An
>> alternative approach would be to update set_multilib_dir and
>> print_multilib_info
>> to lookup configure_default_options in configargs.h as well.
>>
>> Note that this didn't fail to build in gcc-4.6, but I can't see yet what
>> change
>> did cause the build failure.
>>
>> I didn't check if other targets need an update as well.
>>
>> Ok for the trunk?
>>
>> Matthias
>>
>
> This patch doesn't appear to be based of FSF trunk...
>
>
>> @@ -68,6 +82,28 @@
>> "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
>>
>
> This pre-amble code has never existed in the FSF build.
>
>
> Please ensure you are testing patches against the FSF sources, not some
> custom variant.
it was, not only on "some custom variant". The second chunk applies with fuzz
2, and I didn't notice when submitting.
Matthias
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 187013)
+++ gcc/config.gcc (working copy)
@@ -3013,10 +3013,18 @@
esac
case "$with_float" in
- "" \
- | soft | hard | softfp)
+ "")
# OK
;;
+ soft)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=0"
+ ;;
+ softfp)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=1"
+ ;;
+ hard)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=2"
+ ;;
*)
echo "Unknown floating point type used in
--with-float=$with_float" 1>&2
exit 1
@@ -3060,6 +3068,9 @@
"" \
| arm | thumb )
#OK
+ if test "$with_mode" = thumb; then
+ tm_defines="${tm_defines}
TARGET_CONFIGURED_THUMB_MODE=1"
+ fi
;;
*)
echo "Unknown mode used in --with-mode=$with_mode"
Index: gcc/config/arm/linux-eabi.h
===
--- gcc/config/arm/linux-eabi.h (revision 187013)
+++ gcc/config/arm/linux-eabi.h (working copy)
@@ -35,7 +35,21 @@
target hardware. If you override this to use the hard-float ABI then
change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well. */
#undef TARGET_DEFAULT_FLOAT_ABI
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=hard"
+#elif TARGET_CONFIGURED_FLOAT_ABI == 1
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFTFP
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=softfp"
+#else
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=soft"
+#endif
+#else
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=soft"
+#endif
/* We default to the "aapcs-linux" ABI so that enums are int-sized by
default. */
@@ -78,6 +92,28 @@
%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"
+/* Set the multilib defaults according the configuration, needed to
+ let gcc -print-multi-dir do the right thing. */
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define MULTILIB_DEFAULT_ENDIAN "mbig-endian"
+#else
+#define MULTILIB_DEFAULT_ENDIAN "mlittle-endian"
+#endif
+
+#ifndef TARGET_CONFIGURED_THUMB_MODE
+#define MULTILIB_DEFAULT_MODE "marm"
+#elif TARGET_CONFIGURED_THUMB_MODE == 1
+#define MULTILIB_DEFAULT_MODE "mthumb"
+#else
+#define MULTILIB_DEFAULT_MODE "marm"
+#endif
+
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+ { MULTILIB_DEFAULT_MODE, MULTILIB_DEFAULT_ENDIAN, \
+ MULTILIB_DEFAULT_FLOAT_ABI, "mno-thumb-interwork" }
+
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
#undef LINK_SPEC
Re: [patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
On 02/05/12 15:59, Matthias Klose wrote:
> On 02.05.2012 16:53, Richard Earnshaw wrote:
>> On 02/05/12 14:26, Matthias Klose wrote:
>>> I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
>>> configuration. The reason is that gcc -print-multi-directory doesn't print
>>> anything for the non-default, and gcc -print-multi-lib only prints `.' (and
>>> then
>>> not building the runtime libs for the non-default). The reason is that
>>> set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
>>> linux-elf.h), but not configure_default_options in configargs.h. This
>>> proposed
>>> patch updates MULTILIB_DEFAULTS depending on the configure options. An
>>> alternative approach would be to update set_multilib_dir and
>>> print_multilib_info
>>> to lookup configure_default_options in configargs.h as well.
>>>
>>> Note that this didn't fail to build in gcc-4.6, but I can't see yet what
>>> change
>>> did cause the build failure.
>>>
>>> I didn't check if other targets need an update as well.
>>>
>>> Ok for the trunk?
>>>
>>> Matthias
>>>
>>
>> This patch doesn't appear to be based of FSF trunk...
>>
>>
>>> @@ -68,6 +82,28 @@
>>> "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>>> %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
>>>
>>
>> This pre-amble code has never existed in the FSF build.
>>
>>
>> Please ensure you are testing patches against the FSF sources, not some
>> custom variant.
>
> it was, not only on "some custom variant". The second chunk applies with fuzz
> 2, and I didn't notice when submitting.
>
So shouldn't the patch also update the setting of
GLIBC_DYNAMIC_LINKER_DEFAULT?
R.
Re: [RFH / Patch] PR 51222
On 05/01/2012 11:01 PM, Paolo Carlini wrote: Well, not really. The first time walk_template_parms_r is called, t is a SIZEOF_EXPR which remains unhandled, the function returns NULL_TREE. The second time, t is a COMPONENT_REF, thus !TYPE_P (t) is true, TREE_TYPE is NULL, the function immediately returns error_mark_node and the iteration ends (with the correct result that the expression is instantiation-dependent). Ah, I guess we can't get to a FIELD_DECL without going through an expression with null type. OK, can leave out the FIELD_DECL case then with a comment. I also booted and tested a variant, attached, which changes finish_static_assert to also use instantiation_dependent_expression_p and also passes testing: nice, between front-end and library we stress the new function quite a bit more. Great. Let's also use it for sizeof/alignof, controlled with abi_version_at_least (7), since it affects mangling. And then figure out what we're going to to about ABI transition in 4.8... Jason
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Wed, May 2, 2012 at 6:42 AM, H.J. Lu wrote:
> On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
>> Hi H.J,
>>
>> Done now. Patch attached.
>>
>> Thanks,
>> -Sri.
>>
>> On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
>>> On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam wrote:
Hi,
New patch attached, updated test case and fixed bugs related to
__PRETTY_FUNCTION_.
Patch also available for review here:
http://codereview.appspot.com/5752064
>>>
>>> @@ -0,0 +1,39 @@
>>> +/* Simple test case to check if Multiversioning works. */
>>> +/* { dg-do run } */
>>> +/* { dg-options "-O2 -fPIC" } */
>>> +
>>> +#include
>>> +
>>> +int foo ();
>>> +int foo () __attribute__ ((target("arch=corei7,sse4.2,popcnt")));
>>> +/* The target operands in this declaration and the definition are
>>> re-ordered.
>>> + This should still work. */
>>> +int foo () __attribute__ ((target("ssse3,avx2")));
>>> +
>>> +int (*p)() = &foo;
>>> +int main ()
>>> +{
>>> + return foo () + (*p)();
>>> +}
>>> +
>>> +int foo ()
>>> +{
>>> + return 0;
>>> +}
>>> +
>>> +int __attribute__ ((target("arch=corei7,sse4.2,popcnt")))
>>> +foo ()
>>> +{
>>> + assert (__builtin_cpu_is ("corei7")
>>> + && __builtin_cpu_supports ("sse4.2")
>>> + && __builtin_cpu_supports ("popcnt"));
>>> + return 0;
>>> +}
>>> +
>>> +int __attribute__ ((target("avx2,ssse3")))
>>> +foo ()
>>> +{
>>> + assert (__builtin_cpu_supports ("avx2")
>>> + && __builtin_cpu_supports ("ssse3"));
>>> + return 0;
>>> +}
>>>
>>> This test will pass if
>>>
>>> int foo ()
>>> {
>>> return 0;
>>> }
>>>
>>> is selected on processors with AVX. The run-time test should
>>> check that the right function is selected on the target processor,
>>> not the selected function matches the target attribute. You can
>>> do it by returning different values for each foo and call cpuid
>>> to check if the right foo is selected.
>>>
>>> You should add a testcase for __builtin_cpu_supports to check
>>> all valid arguments.
>>>
>>> --
>>> H.J.
>
> 2 questions:
>
> 1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
> foo for AVX and SSE3, on AVX processors, which foo will be
> selected?
foo for AVX will get called since that appears ahead.
The dispatching is done in the same order in which the functions are
specified. If, potentially, two foo versions can be dispatched for an
architecture, the first foo will get called. There is no way right
now to specify the order in which the dispatching should be done.
> 2. I don't see any tests for __builtin_cpu_supports ("XXX")
> nor __builtin_cpu_is ("XXX"). I think you need tests for
> them.
This is already there as part of the previous CPU detection patch that
was submitted. Please see gcc.target/i386/builtin_target.c. Did you
want something else?
>
> --
> H.J.
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
> Otherwise, this looks good. > Thanks, I've applied inputs! Comitted to MT: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00047.html Thanks, K
Re: [patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
On 02.05.2012 17:02, Richard Earnshaw wrote:
> On 02/05/12 15:59, Matthias Klose wrote:
>> On 02.05.2012 16:53, Richard Earnshaw wrote:
>>> On 02/05/12 14:26, Matthias Klose wrote:
I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
configuration. The reason is that gcc -print-multi-directory doesn't print
anything for the non-default, and gcc -print-multi-lib only prints `.'
(and then
not building the runtime libs for the non-default). The reason is that
set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
linux-elf.h), but not configure_default_options in configargs.h. This
proposed
patch updates MULTILIB_DEFAULTS depending on the configure options. An
alternative approach would be to update set_multilib_dir and
print_multilib_info
to lookup configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what
change
did cause the build failure.
I didn't check if other targets need an update as well.
Ok for the trunk?
Matthias
>>>
>>> This patch doesn't appear to be based of FSF trunk...
>>>
>>>
@@ -68,6 +82,28 @@
"%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
%{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
>>>
>>> This pre-amble code has never existed in the FSF build.
>>>
>>>
>>> Please ensure you are testing patches against the FSF sources, not some
>>> custom variant.
>>
>> it was, not only on "some custom variant". The second chunk applies with
>> fuzz
>> 2, and I didn't notice when submitting.
>>
>
> So shouldn't the patch also update the setting of
> GLIBC_DYNAMIC_LINKER_DEFAULT?
like this one?
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 187013)
+++ gcc/config.gcc (working copy)
@@ -3013,10 +3013,18 @@
esac
case "$with_float" in
- "" \
- | soft | hard | softfp)
+ "")
# OK
;;
+ soft)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=0"
+ ;;
+ softfp)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=1"
+ ;;
+ hard)
+ tm_defines="${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=2"
+ ;;
*)
echo "Unknown floating point type used in
--with-float=$with_float" 1>&2
exit 1
@@ -3060,6 +3068,9 @@
"" \
| arm | thumb )
#OK
+ if test "$with_mode" = thumb; then
+ tm_defines="${tm_defines}
TARGET_CONFIGURED_THUMB_MODE=1"
+ fi
;;
*)
echo "Unknown mode used in --with-mode=$with_mode"
Index: gcc/config/arm/linux-eabi.h
===
--- gcc/config/arm/linux-eabi.h (revision 187013)
+++ gcc/config/arm/linux-eabi.h (working copy)
@@ -35,7 +35,21 @@
target hardware. If you override this to use the hard-float ABI then
change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well. */
#undef TARGET_DEFAULT_FLOAT_ABI
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=hard"
+#elif TARGET_CONFIGURED_FLOAT_ABI == 1
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFTFP
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=softfp"
+#else
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=soft"
+#endif
+#else
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI "mfloat-abi=soft"
+#endif
/* We default to the "aapcs-linux" ABI so that enums are int-sized by
default. */
@@ -71,13 +85,43 @@
#undef GLIBC_DYNAMIC_LINKER
#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
#define GLIBC_DYNAMIC_LINKER \
"%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"
+/* Set the multilib defaults according the configuration, needed to
+ let gcc -print
Re: [PATCH, reload] Fix bug pr52804, RELOAD pass reloads wrong register on ARM for cortex-m0
Bin Cheng wrote: > In short, I think the confliction of reloads with type > RELOAD_FOR_INPADDR_ADDRESS > and type RELOAD_FOR_INPUT_ADDRESS should be handled in > "reload_reg_reaches_end_p". > Also I think RELOAD_FOR_OUTPUT_ADDRESS/RELOAD_FOR_OUTADDR_ADDRESS have the > issue > symmetrically, though I have no test case for it. Yes, I agree with your reasoning here. This looks like an oversight. > PR target/52804 > * reload1.c (reload_reg_reaches_end_p): Check whether successor > reload with > type RELOAD_FOR_INPUT_ADDRESS kills reload register of current one > with type > RELOAD_FOR_INPADDR_ADDRESS. This is OK. (You also ought to mention the RELOAD_FOR_OUTADDR_ADDRESS part of the change in the ChangeLog.) Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Wed, May 2, 2012 at 8:08 AM, Sriraman Tallam wrote:
> On Wed, May 2, 2012 at 6:42 AM, H.J. Lu wrote:
>> On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
>>> Hi H.J,
>>>
>>> Done now. Patch attached.
>>>
>>> Thanks,
>>> -Sri.
>>>
>>> On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam
wrote:
> Hi,
>
> New patch attached, updated test case and fixed bugs related to
> __PRETTY_FUNCTION_.
>
> Patch also available for review here:
> http://codereview.appspot.com/5752064
@@ -0,0 +1,39 @@
+/* Simple test case to check if Multiversioning works. */
+/* { dg-do run } */
+/* { dg-options "-O2 -fPIC" } */
+
+#include
+
+int foo ();
+int foo () __attribute__ ((target("arch=corei7,sse4.2,popcnt")));
+/* The target operands in this declaration and the definition are
re-ordered.
+ This should still work. */
+int foo () __attribute__ ((target("ssse3,avx2")));
+
+int (*p)() = &foo;
+int main ()
+{
+ return foo () + (*p)();
+}
+
+int foo ()
+{
+ return 0;
+}
+
+int __attribute__ ((target("arch=corei7,sse4.2,popcnt")))
+foo ()
+{
+ assert (__builtin_cpu_is ("corei7")
+ && __builtin_cpu_supports ("sse4.2")
+ && __builtin_cpu_supports ("popcnt"));
+ return 0;
+}
+
+int __attribute__ ((target("avx2,ssse3")))
+foo ()
+{
+ assert (__builtin_cpu_supports ("avx2")
+ && __builtin_cpu_supports ("ssse3"));
+ return 0;
+}
This test will pass if
int foo ()
{
return 0;
}
is selected on processors with AVX. The run-time test should
check that the right function is selected on the target processor,
not the selected function matches the target attribute. You can
do it by returning different values for each foo and call cpuid
to check if the right foo is selected.
You should add a testcase for __builtin_cpu_supports to check
all valid arguments.
--
H.J.
>>
>> 2 questions:
>>
>> 1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
>> foo for AVX and SSE3, on AVX processors, which foo will be
>> selected?
>
> foo for AVX will get called since that appears ahead.
>
> The dispatching is done in the same order in which the functions are
> specified. If, potentially, two foo versions can be dispatched for an
> architecture, the first foo will get called. There is no way right
> now to specify the order in which the dispatching should be done.
This is very fragile. We know ISAs and processors. The source
order should be irrelevant.
>
>> 2. I don't see any tests for __builtin_cpu_supports ("XXX")
>> nor __builtin_cpu_is ("XXX"). I think you need tests for
>> them.
>
> This is already there as part of the previous CPU detection patch that
> was submitted. Please see gcc.target/i386/builtin_target.c. Did you
> want something else?
gcc.target/i386/builtin_target.c doesn't test if __builtin_cpu_supports ("XXX")
and __builtin_cpu_is ("XXX") are implemented correctly.
--
H.J.
Re: PR 53115
On Tue, May 1, 2012 at 1:23 PM, François Dumont wrote: > unordered_multilmap test added, attached patch applied to 4.7 branch and > trunk. > > This bug was not so difficult to fix. It would even have been quite easy to > detect with a good test coverage tool showing that not all possible path had > been tested in this method. I hope to be able to make some progress on this > subject in the future. However I will have a try with Valgrind. > > I can only add comment in bugzilla so I let you set this issue as resolved. > > François > > > I will have a run with Valgrind > > 2012-05-01 François Dumont > > PR libstdc++/53115 > * include/bits/hashtable.h > (_Hashtable<>::_M_rehash_aux(size_type, false_type)): Fix buckets > after insertion of several equivalent elements. > * testsuite/23_containers/unordered_multiset/insert/53115.cc: New. > * testsuite/23_containers/unordered_multimap/insert/53115.cc: New. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53193 It may need other fixes from trunk. -- H.J.
Re: [patch] skip tpf configure tests
> * crossconfig.m4: Since we know that all TPF builds are cross- > builds and cannot run configuration-time link tests, do not > allow it; just go with known supported linker options. > * configure: Regenerate (called as GLIBCXX_CROSSCONFIG). OK -benjamin
[v3] hashtable fw decl fix
This patchlette needed for versioned builds, just makes
declaration/foward declaration consistent.
-benjamin
tested x86/linux
tested x86/linux versioned namespacesdiff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index 3b43510..a42d3d3 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -33,12 +33,16 @@
namespace std _GLIBCXX_VISIBILITY(default)
{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
template
class _Hashtable;
+_GLIBCXX_END_NAMESPACE_VERSION
+
namespace __detail
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
Re: Patches to enable -ftrack-macro-expansion by default
On Tue, May 1, 2012 at 6:04 PM, Dodji Seketeli wrote: >>> pfile->context = XNEW (cpp_context); >>> + memset (pfile->context, 0, sizeof (cpp_context)); >> >> You can use XCNEW instead of XNEW + memset. >> >> OK with that change. > > Thank you. > > Here is the patch I will commit when Uros confirms that it fixes the > problem for him on alpha. Yes, the patch works OK on alpha and fixes the ICE in macro-4.c test. Thanks, Uros.
[PATCH] Fix predcom VTA ICE (PR debug/53174)
Hi!
single_nonlooparound_use ignores debug uses (otherwise we end up with
-fcompare-debug failures), but when removing stmts we need to reset
the debug uses, otherwise e.g. the testcase below ICEs. Alex, if you have
better ideas how to reconstruct the debug stmts instead, feel free to
follow-up, but it won't be easy IMHO.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-05-02 Jakub Jelinek
PR debug/53174
* tree-predcom.c (remove_stmt): Call reset_debug_uses on stmts being
removed.
* gcc.dg/pr53174.c: New test.
--- gcc/tree-predcom.c.jj 2012-03-28 19:39:21.0 +0200
+++ gcc/tree-predcom.c 2012-05-02 13:14:14.765575987 +0200
@@ -1707,6 +1707,7 @@ remove_stmt (gimple stmt)
{
name = PHI_RESULT (stmt);
next = single_nonlooparound_use (name);
+ reset_debug_uses (stmt);
psi = gsi_for_stmt (stmt);
remove_phi_node (&psi, true);
@@ -1728,6 +1729,7 @@ remove_stmt (gimple stmt)
gcc_assert (TREE_CODE (name) == SSA_NAME);
next = single_nonlooparound_use (name);
+ reset_debug_uses (stmt);
mark_virtual_ops_for_renaming (stmt);
gsi_remove (&bsi, true);
--- gcc/testsuite/gcc.dg/pr53174.c.jj 2012-05-02 13:36:29.466948569 +0200
+++ gcc/testsuite/gcc.dg/pr53174.c 2012-05-02 13:35:59.0 +0200
@@ -0,0 +1,67 @@
+/* PR debug/53174 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -g" } */
+
+int w, h;
+
+void
+bar (float (*x)[4], int y, int z)
+{
+ int a, b, c, d, e, f, g;
+
+ a = 2;
+ b = 2;
+ c = 274;
+ d = 274;
+ if (!z)
+a = 12;
+ if (!y)
+b = 12;
+ if (z + 266 >= h - 2)
+c = 8 + h - z;
+ if (y + 266 >= w - 2)
+d = 8 + w - y;
+ for (e = a; e < c; e++)
+for (f = b, g = e * 276 + f; f < d; f++, g++)
+ {
+ float (*h)[4] = x + (g - 277);
+ float k = (*h)[0];
+ float l = (*h)[1];
+ float m = (*h)[2];
+ h++;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ h++;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ h += 274;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ h += 2;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ h += 274;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ h++;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ h++;
+ k += (*h)[0];
+ l += (*h)[1];
+ m += (*h)[2];
+ k *= 0.125f;
+ l *= 0.125f;
+ m *= 0.125f;
+ k = k + (x[g][1] - l);
+ m = m + (x[g][1] - l);
+ x[g][0] = k;
+ x[g][2] = m;
+ }
+}
Jakub
Re: Patches to enable -ftrack-macro-expansion by default
Uros Bizjak writes: > On Tue, May 1, 2012 at 6:04 PM, Dodji Seketeli wrote: > pfile->context = XNEW (cpp_context); + memset (pfile->context, 0, sizeof (cpp_context)); >>> >>> You can use XCNEW instead of XNEW + memset. >>> >>> OK with that change. >> >> Thank you. >> >> Here is the patch I will commit when Uros confirms that it fixes the >> problem for him on alpha. > > Yes, the patch works OK on alpha and fixes the ICE in macro-4.c test. Thanks. I have committed the patch to the mainline, at SVN revision r187054. -- Dodji
RE: [PATCH 12/13] Adjust relevant test cases wrt -ftrack-macro-expansion=[0|2]
There are a couple more test that need adjusting:
gcc.dg/fixed-point/operator-bitwise.c
gcc.dg/fixed-point/composite-type.c
These tests fail on arm-none-eabi.
Below is a patch that fixes them.
Thanks,
Greta
gcc/testsuite
2012-05-02 Greta Yorsh
* gcc.dg/fixed-point/composite-type.c (dg-options): Add
option -ftrack-macro-expansion=0.
* gcc.dg/fixed-point/operator-bitwise.c (dg-options): Add
option -ftrack-macro-expansion=0.
diff --git a/gcc/testsuite/gcc.dg/fixed-point/composite-type.c
b/gcc/testsuite/gcc.dg/fixed-point/composite-type.c
index 5ae1198..026bdaf 100644
--- a/gcc/testsuite/gcc.dg/fixed-point/composite-type.c
+++ b/gcc/testsuite/gcc.dg/fixed-point/composite-type.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-std=gnu99 -O -Wall -Wno-unused" } */
+/* { dg-options "-std=gnu99 -O -Wall -Wno-unused -ftrack-macro-expansion=0"
} */
/* C99 6.2.7: Compatible type and composite type. */
diff --git a/gcc/testsuite/gcc.dg/fixed-point/operator-bitwise.c
b/gcc/testsuite/gcc.dg/fixed-point/operator-bitwise.c
index 31aecf5..6ba817d 100644
--- a/gcc/testsuite/gcc.dg/fixed-point/operator-bitwise.c
+++ b/gcc/testsuite/gcc.dg/fixed-point/operator-bitwise.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-std=gnu99" } */
+/* { dg-options "-std=gnu99 -ftrack-macro-expansion=0" } */
/* C99 6.5.10: Bitwise AND operator.
C99 6.5.11: Bitwise exclusive OR operator.
> -Original Message-
> From: Mike Stump [mailto:mikest...@comcast.net]
> Sent: 30 April 2012 17:09
> To: Dodji Seketeli
> Cc: Gabriel Dos Reis; GCC Patches; Tom Tromey; Jason Merrill; Paolo
> Carlini; Benjamin De Kosnik
> Subject: Re: [PATCH 12/13] Adjust relevant test cases wrt -ftrack-
> macro-expansion=[0|2]
>
> On Apr 29, 2012, at 10:38 AM, Dodji Seketeli wrote:
> > While bootstrapping the tree again, it appeared that an output
> > regression of the objc test objc.dg/foreach-7.m flew below my radar.
>
> > This looks fairly obvious to me, but I am CC-ing Mike Stump, just in
> > case.
>
> That's fine.
Re: [6/6] Fold prev/next into gimple: do it
Hi, On Wed, 2 May 2012, Richard Guenther wrote: > Please remove the flags. Okay. > can you factor out this idiom to sth like gsi_new_seq_from_stmt () or so? > Or gimple_init_seq_pointers? Not necessarily exported. gimple_init_singleton it is. The whole series is now at r187053. Ciao, Michael.
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Wed, May 2, 2012 at 9:05 AM, H.J. Lu wrote:
> On Wed, May 2, 2012 at 8:08 AM, Sriraman Tallam wrote:
>> On Wed, May 2, 2012 at 6:42 AM, H.J. Lu wrote:
>>> On Tue, May 1, 2012 at 7:45 PM, Sriraman Tallam wrote:
Hi H.J,
Done now. Patch attached.
Thanks,
-Sri.
On Tue, May 1, 2012 at 5:08 PM, H.J. Lu wrote:
> On Tue, May 1, 2012 at 4:51 PM, Sriraman Tallam
> wrote:
>> Hi,
>>
>> New patch attached, updated test case and fixed bugs related to
>> __PRETTY_FUNCTION_.
>>
>> Patch also available for review here:
>> http://codereview.appspot.com/5752064
>
> @@ -0,0 +1,39 @@
> +/* Simple test case to check if Multiversioning works. */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fPIC" } */
> +
> +#include
> +
> +int foo ();
> +int foo () __attribute__ ((target("arch=corei7,sse4.2,popcnt")));
> +/* The target operands in this declaration and the definition are
> re-ordered.
> + This should still work. */
> +int foo () __attribute__ ((target("ssse3,avx2")));
> +
> +int (*p)() = &foo;
> +int main ()
> +{
> + return foo () + (*p)();
> +}
> +
> +int foo ()
> +{
> + return 0;
> +}
> +
> +int __attribute__ ((target("arch=corei7,sse4.2,popcnt")))
> +foo ()
> +{
> + assert (__builtin_cpu_is ("corei7")
> + && __builtin_cpu_supports ("sse4.2")
> + && __builtin_cpu_supports ("popcnt"));
> + return 0;
> +}
> +
> +int __attribute__ ((target("avx2,ssse3")))
> +foo ()
> +{
> + assert (__builtin_cpu_supports ("avx2")
> + && __builtin_cpu_supports ("ssse3"));
> + return 0;
> +}
>
> This test will pass if
>
> int foo ()
> {
> return 0;
> }
>
> is selected on processors with AVX. The run-time test should
> check that the right function is selected on the target processor,
> not the selected function matches the target attribute. You can
> do it by returning different values for each foo and call cpuid
> to check if the right foo is selected.
>
> You should add a testcase for __builtin_cpu_supports to check
> all valid arguments.
>
> --
> H.J.
>>>
>>> 2 questions:
>>>
>>> 1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
>>> foo for AVX and SSE3, on AVX processors, which foo will be
>>> selected?
>>
>> foo for AVX will get called since that appears ahead.
>>
>> The dispatching is done in the same order in which the functions are
>> specified. If, potentially, two foo versions can be dispatched for an
>> architecture, the first foo will get called. There is no way right
>> now to specify the order in which the dispatching should be done.
>
> This is very fragile. We know ISAs and processors. The source
> order should be irrelevant.
I am not sure it is always possible keep this dispatching unambiguous
to the user. It might be better to let the user specify a priority for
each version to control the order of dispatching.
Still, one way to implement what you said is to assign a significance
number to each ISA, where the number of sse4 > sse, for instance.
Then, the dispatching can be done in the descending order of
significance. What do you think?
I thought about this earlier and I was thinking along the lines of
letting the user specify a priority for each version, when there is
ambiguity.
>
>>
>>> 2. I don't see any tests for __builtin_cpu_supports ("XXX")
>>> nor __builtin_cpu_is ("XXX"). I think you need tests for
>>> them.
>>
>> This is already there as part of the previous CPU detection patch that
>> was submitted. Please see gcc.target/i386/builtin_target.c. Did you
>> want something else?
>
> gcc.target/i386/builtin_target.c doesn't test if __builtin_cpu_supports
> ("XXX")
> and __builtin_cpu_is ("XXX") are implemented correctly.
Oh, you mean like doing a CPUID again in the test case itself and checking, ok.
Thanks,
-Sri.
>
>
> --
> H.J.
Re: [PATCH, i386, middle-end, tessuite] Intel TSX's HLE.
On Wed, May 2, 2012 at 8:37 AM, Kirill Yukhin wrote: >> Otherwise, this looks good. >> > > Thanks, I've applied inputs! > > Comitted to MT: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00047.html > It caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53194 -- H.J.
[AVR,4.5,Backport] PR39633, PR45263, PR46779, PR50820
Backported the following wrong-code PRs from 4.6 to 4.5.4: PR target/39633 http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187056 PR target/45263 http://gcc.gnu.org/viewcvs?view=revision&revision=187058 PR target/46779 http://gcc.gnu.org/viewcvs?view=revision&revision=187055 PR target/50820 http://gcc.gnu.org/viewcvs?view=revision&revision=187059 Johann
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam wrote:
1. Since AVX > SSE4 > SSSE3 > SSE3 > SSE2 > SSE, with
foo for AVX and SSE3, on AVX processors, which foo will be
selected?
>>>
>>> foo for AVX will get called since that appears ahead.
>>>
>>> The dispatching is done in the same order in which the functions are
>>> specified. If, potentially, two foo versions can be dispatched for an
>>> architecture, the first foo will get called. There is no way right
>>> now to specify the order in which the dispatching should be done.
>>
>> This is very fragile. We know ISAs and processors. The source
>> order should be irrelevant.
>
> I am not sure it is always possible keep this dispatching unambiguous
> to the user. It might be better to let the user specify a priority for
> each version to control the order of dispatching.
>
> Still, one way to implement what you said is to assign a significance
> number to each ISA, where the number of sse4 > sse, for instance.
> Then, the dispatching can be done in the descending order of
> significance. What do you think?
This sounds reasonable. You should also take processor into
account when doing this.
> I thought about this earlier and I was thinking along the lines of
> letting the user specify a priority for each version, when there is
> ambiguity.
>
>>
>>>
2. I don't see any tests for __builtin_cpu_supports ("XXX")
nor __builtin_cpu_is ("XXX"). I think you need tests for
them.
>>>
>>> This is already there as part of the previous CPU detection patch that
>>> was submitted. Please see gcc.target/i386/builtin_target.c. Did you
>>> want something else?
>>
>> gcc.target/i386/builtin_target.c doesn't test if __builtin_cpu_supports
>> ("XXX")
>> and __builtin_cpu_is ("XXX") are implemented correctly.
>
> Oh, you mean like doing a CPUID again in the test case itself and checking,
> ok.
>
Yes. BTW, I think you should also add FMA support to
config/i386/i386-cpuinfo.c.
Thanks.
--
H.J.
Re: [RFH / Patch] PR 51222]
Hi,
On 05/01/2012 11:01 PM, Paolo Carlini wrote:
Well, not really. The first time walk_template_parms_r is called, t is a
SIZEOF_EXPR which remains unhandled, the function returns NULL_TREE. The
second time, t is a COMPONENT_REF, thus !TYPE_P (t) is true, TREE_TYPE
is NULL, the function immediately returns error_mark_node and the
iteration ends (with the correct result that the expression is
instantiation-dependent).
Ah, I guess we can't get to a FIELD_DECL without going through an
expression with null type. OK, can leave out the FIELD_DECL case then
with a comment.
Ok.
I also booted and tested a variant, attached, which changes
finish_static_assert to also use instantiation_dependent_expression_p
and also passes testing: nice, between front-end and library we
stress the new function quite a bit more.
Great. Let's also use it for sizeof/alignof, controlled with
abi_version_at_least (7), since it affects mangling.
Ok. I'm attaching what I booted and tested successfully.
Is it now good enough to go in to resolve PR51222? Otherwise, if we
aren't still not completely sure about bits outside PR51222 proper,
maybe we could split the work in two parts?
And then figure out what we're going to to about ABI transition in
4.8...
This reminds me that maybe it's finally time to break the library ABI. I
guess we may want to discuss the issue at the Cauldron too.
Paolo.
/cp
2012-05-02 Paolo Carlini
PR c++/51222
* pt.c (for_each_template_parm): Rename to walk_template_parms,
add check_types bool parameter.
(mark_template_parm, uses_template_parms_level): Adjust.
(instantiation_dependent_expression_p): New.
(finish_decltype_type, finish_static_assert): Use it.
* typeck.c (cxx_sizeof_expr, cxx_alignof_expr): Likewise.
* cp-tree.h: Update declarations.
/testsuite
2012-05-02 Paolo Carlini
PR c++/51222
* g++.dg/cpp0x/decltype37.C: New.
Index: testsuite/g++.dg/cpp0x/decltype37.C
===
--- testsuite/g++.dg/cpp0x/decltype37.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype37.C (revision 0)
@@ -0,0 +1,101 @@
+// PR c++/51222
+// { dg-options -std=c++11 }
+
+template
+struct add_rref {
+ typedef T&& type;
+};
+
+template<>
+struct add_rref {
+ typedef void type;
+};
+
+template
+typename add_rref::type declval();
+
+template()))
+>
+auto f(int) -> char;
+
+template
+auto f(...) -> char(&)[2];
+
+template
+auto g(int) -> char;
+
+template
+auto g(...) -> char(&)[2];
+
+template
+auto f2(int) -> decltype(::delete ::new T(declval()), char());
+
+template
+auto f2(...) -> char(&)[2];
+
+template
+auto g2(int) -> decltype(::delete ::new T(), char());
+
+template
+auto g2(...) -> char(&)[2];
+
+struct C { };
+
+struct A {
+ virtual ~A() = 0;
+};
+
+struct D1 {
+ D1() = delete;
+};
+
+struct D2 {
+ ~D2() = delete;
+};
+
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(g(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+static_assert(sizeof(f(0)) == 2, "Ouch");
+
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(g2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
+static_assert(sizeof(f2(0)) == 2, "Ouch");
Index: cp/typeck.c
===
--- cp/typeck.c (revision 187058)
+++ cp/typeck.c (working copy)
@@ -1581,7 +1581,9 @@ cxx_sizeof_expr (tree e, tsubst_flags_t complain)
i
[Patch, testsuite] missing -ftrack-macro-expansion=0 option in gcc.dg/builtin-stringop-chk-1.c
The test gcc.dg/builtin-stringop-chk-1.c fails on arm-none-eabi because the
command line option -ftrack-macro-expansion=0 is missing.
This command-line option has recently been added to dg-options directive in
this test, but for arm targets the first dg-options directive in the test is
overwritten by a second dg-options that does not contain
-ftrack-macro-expansion=0.
This patch replaces the second dg-options directive with
dg-additional-options. Fixed test passes on qemu.
OK for trunk?
Thanks,
Greta
gcc/testsuite
2012-05-02 Greta Yorsh
* gcc.dg/builtin-stringop-chk-1.c (dg-options): Replace
dg-options for target arm with dg-additional-options.
diff --git a/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
b/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
index beecab6..5cec6b3 100644
--- a/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
+++ b/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
@@ -2,7 +2,7 @@
are emitted properly. */
/* { dg-do compile } */
/* { dg-options "-O2 -std=gnu99 -ftrack-macro-expansion=0" } */
-/* { dg-options "-mstructure-size-boundary=8 -O2 -std=gnu99" { target
arm*-*-* } } */
+/* { dg-additional-options "-mstructure-size-boundary=8" { target arm*-*-*
} } */
extern void abort (void);
Re: Backported r187026 from branches/google/gcc-4_6 (issue 6148044)
On 2012/05/01 22:51:22, jingyu wrote: 1) Please add an description entry to libgcc/ChangeLog.google-4_6 Done. 2) Your gcc/ChangeLog.google-4_6 change reverts someone else's change. Please update it and also update the time of your entry. Done. 3) Please list in the Description field what tests you have done. Done. Thanks, Jing On 2012/05/01 22:40:12, asharif wrote: > +carrot@ http://codereview.appspot.com/6148044/
Re: [patch] Update DWARF codes for Fission
>> This patch to include/dwarf2.def updates the DW_FORM and DW_AT codes >> for the Fission extensions. We've eliminated DW_FORM_GNU_ref_index, >> and replaced DW_AT_GNU_ref_base with DW_AT_GNU_ranges_base. (The wiki >> page at http://gcc.gnu.org/wiki/DebugFission has been updated.) >> >> OK for binutils and gcc? > > Okay. Thanks, committed to both repositories. -cary
Re: No documentation of -fsched-pressure-algorithm
Ian Lance Taylor writes:
> Richard Sandiford writes:
>> Well, given the replies from you, Ian and Vlad (when reviewing the patch),
>> I feel once again in a minority of one here :-) but... I just don't
>> think we should be advertising this sort of stuff to users. Not because
>> I'm trying to be cliquey, but because any time the user ends up having
>> to use stuff like this represents a failure on the part of the compiler.
>
> I think it's perfectly reasonable to have tuning knobs that are reserved
> for experts or people with too much time on their hands. I just think
> that we already have a mechanism for that via --param. For --param the
> docs say
>
> The names of specific parameters, and the meaning of the values, are
> tied to the internals of the compiler, and are subject to change
> without notice in future releases.
>
> I think that is the kind of thing you are talking about. I think that
> for compiler tuning knobs we should use the mechanism that already
> exists, rather than introducing a new mechanism of undocumented -f
> options.
OK, fair enough. How does this patch look? I tested it before I got
Richard E's message, but it still seems the weight of opinion is behind
--param.
Bootstrapped & regression-tested on x86_64-linux-gnu. Which I know
is meaningful because I forgot the PARAM_VALUE in the first cut and
got a bunch of extra ICEs. I also tried the --param values out to
make sure that the right algorithm was being chosen, and that the
default was unchanged. OK to install?
Richard
gcc/
* doc/invoke.texi (sched-pressure-algorithm): Document new --param.
* common.opt (fsched-pressure-algorithm=): Remove.
* flag-types.h (sched_pressure_algorithm): Move to...
* sched-int.h (sched_pressure_algorithm): ...here.
* params.def (sched-pressure-algorithm): New param.
* haifa-sched.c (sched_init): Use it to initialize sched_pressure.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi 2012-05-01 21:36:18.091969459 +0100
+++ gcc/doc/invoke.texi 2012-05-02 19:38:02.725960400 +0100
@@ -9329,6 +9329,17 @@ Set the maximum number of instructions e
reassociated tree. This parameter overrides target dependent
heuristics used by default if has non zero value.
+@item sched-pressure-algorithm
+Choose between the two available implementations of
+@option{-fsched-pressure}. Algorithm 1 is the original implementation
+and is the more likely to prevent instructions from being reordered.
+Algorithm 2 was designed to be a compromise between the relatively
+conservative approach taken by algorithm 1 and the rather aggressive
+approach taken by the default scheduler. It relies more heavily on
+having a regular register file and accurate register pressure classes.
+See @file{haifa-sched.c} in the GCC sources for more details.
+
+The default choice depends on the target.
@end table
@end table
Index: gcc/common.opt
===
--- gcc/common.opt 2012-05-01 21:36:18.092969459 +0100
+++ gcc/common.opt 2012-05-02 19:21:36.166989085 +0100
@@ -1665,19 +1665,6 @@ fsched-pressure
Common Report Var(flag_sched_pressure) Init(0) Optimization
Enable register pressure sensitive insn scheduling
-fsched-pressure-algorithm=
-Common Joined RejectNegative Enum(sched_pressure_algorithm)
Var(flag_sched_pressure_algorithm) Init(SCHED_PRESSURE_WEIGHTED)
--fsched-pressure-algorithm=[weighted|model] Set the pressure-scheduling
algorithm
-
-Enum
-Name(sched_pressure_algorithm) Type(enum sched_pressure_algorithm)
UnknownError(unknown % algorithm %qs)
-
-EnumValue
-Enum(sched_pressure_algorithm) String(weighted) Value(SCHED_PRESSURE_WEIGHTED)
-
-EnumValue
-Enum(sched_pressure_algorithm) String(model) Value(SCHED_PRESSURE_MODEL)
-
fsched-spec
Common Report Var(flag_schedule_speculative) Init(1) Optimization
Allow speculative motion of non-loads
Index: gcc/flag-types.h
===
--- gcc/flag-types.h2012-05-01 21:36:18.093969459 +0100
+++ gcc/flag-types.h2012-05-02 19:21:36.150989087 +0100
@@ -106,14 +106,6 @@ enum symbol_visibility
};
#endif
-/* The algorithm used to implement -fsched-pressure. */
-enum sched_pressure_algorithm
-{
- SCHED_PRESSURE_NONE,
- SCHED_PRESSURE_WEIGHTED,
- SCHED_PRESSURE_MODEL
-};
-
/* The algorithm used for the integrated register allocator (IRA). */
enum ira_algorithm
{
Index: gcc/sched-int.h
===
--- gcc/sched-int.h 2012-05-01 21:36:18.092969459 +0100
+++ gcc/sched-int.h 2012-05-02 19:21:36.166989085 +0100
@@ -37,6 +37,14 @@ #define GCC_SCHED_INT_H
enum sched_pass_id_t { SCHED_PASS_UNKNOWN, SCHED_RGN_PASS, SCHED_EBB_PASS,
SCHED_SMS_PASS, SCHED_SEL_PASS };
+/* The algorithm used to implement -fsched-pressure. */
+enum sched_p
Re: PR 53115
On 05/02/2012 06:23 PM, H.J. Lu wrote: On Tue, May 1, 2012 at 1:23 PM, François Dumont wrote: unordered_multilmap test added, attached patch applied to 4.7 branch and trunk. This bug was not so difficult to fix. It would even have been quite easy to detect with a good test coverage tool showing that not all possible path had been tested in this method. I hope to be able to make some progress on this subject in the future. However I will have a try with Valgrind. I can only add comment in bugzilla so I let you set this issue as resolved. François I will have a run with Valgrind 2012-05-01 François Dumont PR libstdc++/53115 * include/bits/hashtable.h (_Hashtable<>::_M_rehash_aux(size_type, false_type)): Fix buckets after insertion of several equivalent elements. * testsuite/23_containers/unordered_multiset/insert/53115.cc: New. * testsuite/23_containers/unordered_multimap/insert/53115.cc: New. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53193 It may need other fixes from trunk. I run tests before updating FSF copyright year. Sorry
[patch] For alpha-vms, unset flag_jump_tables if flag_pic is nonzero
Hello,
alpha-vms is the only target that does not define
ASM_OUTPUT_ADDR_DIFF_ELT. That makes the code in stmt.c to handle this
case alpha-vms specific. But there is a better way to handle this:
Just mimic -fno-jump-tables if flag_pic is nonzero.
Tested by building a cross-compiler for alpha-dec-vms and verifying
that flag_jump_tables==0 in expand_case.
OK for trunk?
Ciao!
Steven
* config/alpha/vms.h (SUBTARGET_OVERRIDE_OPTIONS): For pic code,
unset flag_jump_tables.
* stmt.c (expand_case): Remove special flag_pic case conditional
on ASM_OUTPUT_ADDR_DIFF_ELT not being defined.
Index: config/alpha/vms.h
===
--- config/alpha/vms.h (revision 187046)
+++ config/alpha/vms.h (working copy)
@@ -257,7 +257,15 @@ typedef struct {int num_args; enum avms_
#undef ASM_FINAL_SPEC
/* The VMS convention is to always provide minimal debug info
- for a traceback unless specifically overridden. */
+ for a traceback unless specifically overridden.
+
+ Because ASM_OUTPUT_ADDR_DIFF_ELT is not defined for alpha-vms,
+ jump tables cannot be output for PIC code, because you can't put
+ an absolute address in a readonly section. Putting the table in
+ a writable section is a security hole. Therefore, we unset the
+ flag_jump_tables flag, forcing switch statements to be expanded
+ using decision trees. There are probably other ways to address
+ this issue, but using a decision tree is clearly safe. */
#undef SUBTARGET_OVERRIDE_OPTIONS
#define SUBTARGET_OVERRIDE_OPTIONS \
@@ -268,6 +276,8 @@ do {
write_symbols = VMS_DEBUG;\
debug_info_level = DINFO_LEVEL_TERSE; \
} \
+ if (flag_pic == 1)\
+ flag_jump_tables = 0; \
} while (0)
#undef LINK_SPEC
Index: stmt.c
===
--- stmt.c (revision 187046)
+++ stmt.c (working copy)
@@ -2198,9 +2198,6 @@ expand_case (gimple stmt)
/* RANGE may be signed, and really large ranges will show up
as negative numbers. */
|| compare_tree_int (range, 0) < 0
-#ifndef ASM_OUTPUT_ADDR_DIFF_ELT
- || flag_pic
-#endif
|| !flag_jump_tables
|| TREE_CONSTANT (index_expr)
/* If neither casesi or tablejump is available, we can
Re: [PING] iwMMXt patches
On Tue, Apr 17, 2012 at 4:17 PM, Matt Turner wrote: > Are these patches ready to go in? It looks like they were ack'd. > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01815.html > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01817.html > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01816.html > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01818.html > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01819.html > > We (OLPC) will need these patches for reasonable iwMMXt performance > and the ability to use VFP and iwMMXt together. > > Thanks, > Matt Xinyu, With these patches I don't see a new -mcpu flag. Isn't a tune/cpu flag the normal way to activate this code? Other .md files have statements like (eq_attr "tune" "cortexa8"), but I don't see how to turn on the marvell-f-iwmmxt attribute, ie (eq_attr "marvell_f_iwmmxt" "yes"). Please let me know. Thanks, Matt
Re: [Patch, libfortran] Fix handling of temporary files
PING #2 On Thu, Apr 26, 2012 at 12:19 AM, Janne Blomqvist wrote: > PING! > > On Thu, Apr 19, 2012 at 01:18, Janne Blomqvist > wrote: >> Hi, >> >> the attached patch implements some fixes for handling STATUS="SCRATCH" files. >> >> - Currently, we check GFORTRAN_TMPDIR, TMP, and TEMP environment >> variables, but not the POSIX and GNU standard TMPDIR. As specifying a >> temporary directory depending on the compiler used to create an >> application doesn't make much sense, the patch just uses the standard >> TMPDIR (on Windows TMP and TEMP are used, and on MingW/Cygwin those >> variables are still checked) >> >> - The patch tries to create a temporary file in the first possible >> directory, and tries the next directory in the list if the current one >> fails, and so on. Document this search logic. >> >> - Use the macro P_tmpdir which is available on many systems. >> >> - If the program is privileged, we shouldn't trust path style >> environment variables. The patch fixes this for TMPDIR and also for >> the logic figuring out where addr2line is. >> >> Regtested on x86_64-unknown-linux-gnu, Ok for trunk? >> >> gcc/fortran ChangeLog: >> >> 2012-04-19 Janne Blomqvist >> >> * gfortran.texi (GFORTRAN_TMPDIR): Rename to TMPDIR, explain >> algorithm for choosing temp directory. >> >> >> libgfortran ChangeLog: >> >> 2012-04-19 Janne Blomqvist >> >> * config.h.in: Regenerated. >> * configure: Regenerated. >> * configure.ac: Add checks for getegid and __secure_getenv. >> * io/unix.c (P_tmpdir): Fallback definition for macro. >> (tempfile_open): New function. >> (tempfile): Use secure_getenv, call tempfile_open to try each >> directory in turn. >> * libgfortran.h (DEFAULT_TMPDIR): Remove macro. >> (secure_getenv): New macro/prototype. >> * runtime/environ.c (secure_getenv): New function. >> (variable_table): Rename GFORTRAN_TMPDIR to TMPDIR. >> * runtime/main.c (find_addr2line): Use secure_getenv. >> >> -- >> Janne Blomqvist > > > > -- > Janne Blomqvist -- Janne Blomqvist
Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes, take 2
PING #2 On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist wrote: > PING! > > On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist > wrote: >> Hi, >> >> the attached patch implements a few fixes and cleanups for the MOD and >> MODULO intrinsics. >> >> - When the arguments are constant, use mpfr_fmod instead of the naive >> algorithms which are numerically unstable for large arguments. This >> extends the PR 24518 fix to constant arguments as well, and makes the >> compile-time evaluation match the runtime implementation which also >> uses fmod in the same manner. >> >> - Remove the old fallback path for the case builtin_fmod is not >> available, as the builtin is AFAICS always available. >> >> - Specify the behavior wrt. the sign and magnitude of the result, >> mention this in the documentation. This includes signed zeros which >> now behave similar to other finite values. I.e. for MOD(A, P) the >> result has the sign of A and a magnitude less than that of P, and for >> MODULO(A, P) the result has the sign of P and a magnitude less than >> that of P. As a (minor?) caveat, at runtime this depends on the >> implementation of the fmod function in the target C library. But, a >> fmod that follows C99 Annex F implements this behavior. >> >> Regtested on x86_64-unknown-linux-gnu, Ok for trunk? >> >> 2012-04-19 Janne Blomqvist >> >> PR fortran/49010 >> PR fortran/24518 >> * intrinsic.texi (MOD, MODULO): Mention sign and magnitude of result. >> * simplify.c (gfc_simplify_mod): Use mpfr_fmod. >> (gfc_simplify_modulo): Likewise, use copysign to fix the result if >> zero. >> * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as >> builtin_fmod is always available. For modulo, call copysign to fix >> the result when signed zeros are enabled. >> >> >> -- >> Janne Blomqvist > > > > -- > Janne Blomqvist -- Janne Blomqvist
Re: [Patch, fortran] PR 52428 Reading of large negative values and range checking
PING On Thu, Apr 26, 2012 at 12:08 AM, Janne Blomqvist wrote: > Hi, > > currently when -frange-check is enabled, we check for overflow when > doing a formatted read of an integer value. This check, however, is > against the Fortran numerical model (see 13.4 in F2008), which defines > a symmetric interval [-huge(), huge()], whereas all targets gfortran > supports use a two's complement representation with a range of > [-huge()-1, huge()]. > > However, there is no checking against the numerical model when doing > arithmetic, and thus we can generate and write the value -huge()-1, > but we cannot read it back in! With the -fno-range-check option, this > overflow checking can be disabled, but at the cost of disabling all > overflow checking, which leads to reading nonsense values if the > hardware supported range overflows. > > The attached patch changes this logic such that overflow checking > against the hardware supported range [-huge()-1, huge()] is always > done when reading, regardless of the -frange-check flag setting. This > also seems to be what ifort 12.0 does, I haven't checked other > compilers. > > For some more arguments back and forth, see the PR. > > Regtested on x86_64-unknown-linux-gnu, Ok for trunk? > > gcc/fortran ChangeLog: > > 2012-04-25 Janne Blomqvist > > PR fortran/52428 > * gfortran.texi: Update _gfortran_set_options documentation. > * invoke.texi: Remove runtime behavior description of > -fno-range-check. > * trans-decl.c (create_main_function): Don't pass the range-check > setting to the library. > > > libgfortran ChangeLog: > > 2012-04-25 Janne Blomqvist > > PR fortran/52428 > * io/io.h (max_value): Rename to si_max, remove second argument. > * io/list_read.c (convert_integer): Use unsigned types when > parsing the digits, set max value depending on the sign. > * io/read.c (max_value): Rename to si_max, remove second argument, > simplify. > (read_decimal): Set max value depending on sign, always check > overflow. > (read_radix): Calculate max unsigned value directly. > * libgfortran.h (struct compile_options_t): Remove range_check > field. > * runtime/compile_options.c (set_options): Skip handling > options[7]. > (init_compile_options): Don't set removed field. > > > gcc/testsuite ChangeLog: > > 2012-04-25 Janne Blomqvist > > PR fortran/52428 > * gfortran.dg/int_range_io_1.f90: New test. > > > -- > Janne Blomqvist -- Janne Blomqvist
Re: [patch] For alpha-vms, unset flag_jump_tables if flag_pic is nonzero
On Wed, May 2, 2012 at 9:12 PM, Steven Bosscher wrote:
> Hello,
>
> alpha-vms is the only target that does not define
> ASM_OUTPUT_ADDR_DIFF_ELT. That makes the code in stmt.c to handle this
> case alpha-vms specific. But there is a better way to handle this:
> Just mimic -fno-jump-tables if flag_pic is nonzero.
>
> Tested by building a cross-compiler for alpha-dec-vms and verifying
> that flag_jump_tables==0 in expand_case.
> OK for trunk?
>
> Ciao!
> Steven
>
>
> * config/alpha/vms.h (SUBTARGET_OVERRIDE_OPTIONS): For pic code,
> unset flag_jump_tables.
> * stmt.c (expand_case): Remove special flag_pic case conditional
> on ASM_OUTPUT_ADDR_DIFF_ELT not being defined.
>
> Index: config/alpha/vms.h
> ===
> --- config/alpha/vms.h (revision 187046)
> +++ config/alpha/vms.h (working copy)
> @@ -257,7 +257,15 @@ typedef struct {int num_args; enum avms_
> #undef ASM_FINAL_SPEC
>
> /* The VMS convention is to always provide minimal debug info
> - for a traceback unless specifically overridden. */
> + for a traceback unless specifically overridden.
> +
> + Because ASM_OUTPUT_ADDR_DIFF_ELT is not defined for alpha-vms,
> + jump tables cannot be output for PIC code, because you can't put
> + an absolute address in a readonly section. Putting the table in
> + a writable section is a security hole. Therefore, we unset the
> + flag_jump_tables flag, forcing switch statements to be expanded
> + using decision trees. There are probably other ways to address
> + this issue, but using a decision tree is clearly safe. */
>
> #undef SUBTARGET_OVERRIDE_OPTIONS
> #define SUBTARGET_OVERRIDE_OPTIONS \
> @@ -268,6 +276,8 @@ do {
> write_symbols = VMS_DEBUG; \
> debug_info_level = DINFO_LEVEL_TERSE; \
> } \
> + if (flag_pic == 1) \
> + flag_jump_tables = 0; \
> } while (0)
Obviously the above should instead be:
@@ -268,6 +276,8 @@ do {
write_symbols = VMS_DEBUG;\
debug_info_level = DINFO_LEVEL_TERSE; \
} \
+ if (flag_pic) \
+flag_jump_tables = 0; \
} while (0)
#undef LINK_SPEC
> #undef LINK_SPEC
> Index: stmt.c
> ===
> --- stmt.c (revision 187046)
> +++ stmt.c (working copy)
> @@ -2198,9 +2198,6 @@ expand_case (gimple stmt)
> /* RANGE may be signed, and really large ranges will show up
> as negative numbers. */
> || compare_tree_int (range, 0) < 0
> -#ifndef ASM_OUTPUT_ADDR_DIFF_ELT
> - || flag_pic
> -#endif
> || !flag_jump_tables
> || TREE_CONSTANT (index_expr)
> /* If neither casesi or tablejump is available, we can
Re: [patch] skip tpf configure tests
> > * crossconfig.m4: Since we know that all TPF builds are cross- > > builds and cannot run configuration-time link tests, do not > > allow it; just go with known supported linker options. > > * configure: Regenerate (called as GLIBCXX_CROSSCONFIG). > > OK Thanks! Committed.
Re: [PATCH] Fix overzealous DSE on sparc
David Miller writes: > On targets such as sparc, where ARG_POINTER_REGNUM == > FRAME_POINTER_REGNUM, some of the invariants currently built into DSE > simply do not hold. > > Unlike how DSE assumes, we will in fact see stores to frame pointer > relative addresses for setting up outgoing arguments to a CALL. > > The result is that DSE can eliminate stores that setup those > arguments. > > Two test cases and a DSE debugging dump for one of them can be found > at: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684 > > Richard and Kenneth, can you take a look at this? The patch is > against the 4.7 branch, which is where I've been tracking this down. > I'm currently running it through a regstrap and a glibc build (the > latter of which is where I originally saw this problem) This looks a little odd. ARG_POINTER_REGNUM is for incoming arguments rather than outgoing arguments, so I don't see why it matters whether it's the same as FRAME_POINTER_REGNUM. I think the problem is in the way sparc.c:emit_soft_tfmode_libcall reuses existing MEMs when passing arguments on the stack: if (GET_CODE (this_arg) == MEM && ! force_stack_temp) this_arg = XEXP (this_arg, 0); -ffloat-store forces "a" and "b" to be stored in their argument slots, and emit_soft_tfmode_libcall then passes the address of these incoming argument slots to the libcall. But "a" and "b" don't escape, so DSE thinks that the call can't read them. Even after your change, I think the same thing could happen in cases where -ffloat-store forces local variables rather than incoming arguments to the stack, and where those local variables are then passed as calls. As you say, it works for 32-bit because that uses the normal libcall code. I think the DSE assuption is fair though. If you reuse MEMs like this, then they're no longer just serving the purpose described by MEM_EXPR. Richard
Re: [6/6] Fold prev/next into gimple: do it
On Wed, May 2, 2012 at 10:25 AM, Michael Matz wrote: > Hi, > > On Wed, 2 May 2012, Richard Guenther wrote: > >> Please remove the flags. > > Okay. > >> can you factor out this idiom to sth like gsi_new_seq_from_stmt () or so? >> Or gimple_init_seq_pointers? Not necessarily exported. > > gimple_init_singleton it is. The whole series is now at r187053. It breaks GCC bootstrap: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53197 -- H.J.
RFC: PATCH to correct the scopes of various types
I've been working on a patch to split out the DWARF debug info for
COMDAT functions into COMDAT CUs to go in the same group. One problem I
ran into was that modified versions of function-local types (pointers,
cv-qualified variants, etc) were ending up at global scope. Separately,
Tom Tromey asked me why GCC was using a declaration/definition pair for
namespace-scope types rather than just defining them in the namespace.
This patch fixes both of those issues; it also fixes an issue with
typedef scoping that I haven't been able to reproduce more recently.
Tested x86_64-pc-linux-gnu. Does this make sense to you?
commit c2e5280c5e39f4656c3fadc1a7a049a1678a468e
Author: Jason Merrill
Date: Thu Apr 19 11:21:09 2012 -0400
* dwarf2out.c (modified_type_die): Use scope_die_for.
(gen_type_die_with_usage, dwarf2out_finish): Likewise.
(uses_local_type_r, uses_local_type): New.
(scope_die_for): Keep a type that uses a local type in local scope.
Use get_context_die for namespace and type scope.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 311914a..dbb305a 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -9021,6 +9021,7 @@ modified_type_die (tree type, int is_const_type, int is_volatile_type,
tree item_type = NULL;
tree qualified_type;
tree name, low, high;
+ dw_die_ref mod_scope;
if (code == ERROR_MARK)
return NULL;
@@ -9081,6 +9082,8 @@ modified_type_die (tree type, int is_const_type, int is_volatile_type,
/* Else cv-qualified version of named type; fall through. */
}
+ mod_scope = scope_die_for (type, context_die);
+
if (is_const_type
/* If both is_const_type and is_volatile_type, prefer the path
which leads to a qualified type. */
@@ -9088,17 +9091,17 @@ modified_type_die (tree type, int is_const_type, int is_volatile_type,
|| get_qualified_type (type, TYPE_QUAL_CONST) == NULL_TREE
|| get_qualified_type (type, TYPE_QUAL_VOLATILE) != NULL_TREE))
{
- mod_type_die = new_die (DW_TAG_const_type, comp_unit_die (), type);
+ mod_type_die = new_die (DW_TAG_const_type, mod_scope, type);
sub_die = modified_type_die (type, 0, is_volatile_type, context_die);
}
else if (is_volatile_type)
{
- mod_type_die = new_die (DW_TAG_volatile_type, comp_unit_die (), type);
+ mod_type_die = new_die (DW_TAG_volatile_type, mod_scope, type);
sub_die = modified_type_die (type, is_const_type, 0, context_die);
}
else if (code == POINTER_TYPE)
{
- mod_type_die = new_die (DW_TAG_pointer_type, comp_unit_die (), type);
+ mod_type_die = new_die (DW_TAG_pointer_type, mod_scope, type);
add_AT_unsigned (mod_type_die, DW_AT_byte_size,
simple_type_size_in_bits (type) / BITS_PER_UNIT);
item_type = TREE_TYPE (type);
@@ -9109,10 +9112,10 @@ modified_type_die (tree type, int is_const_type, int is_volatile_type,
else if (code == REFERENCE_TYPE)
{
if (TYPE_REF_IS_RVALUE (type) && dwarf_version >= 4)
- mod_type_die = new_die (DW_TAG_rvalue_reference_type, comp_unit_die (),
+ mod_type_die = new_die (DW_TAG_rvalue_reference_type, mod_scope,
type);
else
- mod_type_die = new_die (DW_TAG_reference_type, comp_unit_die (), type);
+ mod_type_die = new_die (DW_TAG_reference_type, mod_scope, type);
add_AT_unsigned (mod_type_die, DW_AT_byte_size,
simple_type_size_in_bits (type) / BITS_PER_UNIT);
item_type = TREE_TYPE (type);
@@ -15301,10 +15304,36 @@ pop_decl_scope (void)
VEC_pop (tree, decl_scope_table);
}
+/* walk_tree helper function for uses_local_type, below. */
+
+static tree
+uses_local_type_r (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
+{
+ if (!TYPE_P (*tp))
+*walk_subtrees = 0;
+ else
+{
+ tree name = TYPE_NAME (*tp);
+ if (name && DECL_P (name) && decl_function_context (name))
+ return *tp;
+}
+ return NULL_TREE;
+}
+
+/* If TYPE involves a function-local type (including a local typedef to a
+ non-local type), returns that type; otherwise returns NULL_TREE. */
+
+static tree
+uses_local_type (tree type)
+{
+ tree used = walk_tree_without_duplicates (&type, uses_local_type_r, NULL);
+ return used;
+}
+
/* Return the DIE for the scope that immediately contains this type.
- Non-named types get global scope. Named types nested in other
- types get their containing scope if it's open, or global scope
- otherwise. All other types (i.e. function-local named types) get
+ Non-named types that do not involve a function-local type get global
+ scope. Named types nested in namespaces or other types get their
+ containing scope. All other types (i.e. function-local named types) get
the current active scope. */
static dw_die_ref
@@ -15312,18 +15341,24 @@ scope_die_for (tree t, dw_die_ref context_die)
{
dw_die_ref scope_die = NULL;
tree containing_scope;
- int i;
/* Non-types always go in the current scope. */
gcc_assert (TYPE_P (
RFC: PATCH to allow symbolic and sig8 DWARF references in the same compile
Here's my patch to allow -feliminate-dwarf2-dups and
-fdebug-types-section to coexist, so that I can then use symbolic
references for my function COMDAT work. Does this look reasonable to you?
Tested x86_64-pc-linux-gnu.
commit fd1868de6f3793901b8ee5bd9d60ce01643a6d78
Author: Jason Merrill
Date: Tue Apr 24 14:17:56 2012 -0400
* dwarf2out.c (die_struct): Add comdat_type_p flag. Use it instead of
use_debug_types to discriminate the die_id union.
(print_die, assign_symbol_names, copy_decls_walk): Likewise.
(build_abbrev_table, output_die): Likewise.
(prune_unused_types_walk_attribs): Likewise.
(generate_type_signature, copy_declaration_context): Set it.
(remove_child_or_replace_with_skeleton): Set it.
(dwarf2out_start_source_file, dwarf2out_end_source_file): Don't
check use_debug_types.
(dwarf2out_finish): Do break_out_includes after .debug_types.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index dbb305a..305d8db 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -2473,7 +2473,7 @@ typedef struct GTY((chain_circular ("%h.die_sib"))) die_struct {
const char * GTY ((tag ("0"))) die_symbol;
comdat_type_node_ref GTY ((tag ("1"))) die_type_node;
}
- GTY ((desc ("use_debug_types"))) die_id;
+ GTY ((desc ("%0.comdat_type_p"))) die_id;
VEC(dw_attr_node,gc) * die_attr;
dw_die_ref die_parent;
dw_die_ref die_child;
@@ -2482,10 +2482,12 @@ typedef struct GTY((chain_circular ("%h.die_sib"))) die_struct {
dw_offset die_offset;
unsigned long die_abbrev;
int die_mark;
- /* Die is used and must not be pruned as unused. */
- int die_perennial_p;
unsigned int decl_id;
enum dwarf_tag die_tag;
+ /* Die is used and must not be pruned as unused. */
+ BOOL_BITFIELD die_perennial_p : 1;
+ BOOL_BITFIELD comdat_type_p : 1; /* DIE has a type signature */
+ /* Lots of spare bits. */
}
die_node;
@@ -4767,7 +4769,7 @@ print_die (dw_die_ref die, FILE *outfile)
fprintf (outfile, " offset: %ld", die->die_offset);
fprintf (outfile, " mark: %d\n", die->die_mark);
- if (use_debug_types && die->die_id.die_type_node)
+ if (die->comdat_type_p)
{
print_spaces (outfile);
fprintf (outfile, " signature: ");
@@ -4819,13 +4821,13 @@ print_die (dw_die_ref die, FILE *outfile)
case dw_val_class_die_ref:
if (AT_ref (a) != NULL)
{
- if (use_debug_types && AT_ref (a)->die_id.die_type_node)
+ if (AT_ref (a)->comdat_type_p)
{
fprintf (outfile, "die -> signature: ");
print_signature (outfile,
AT_ref (a)->die_id.die_type_node->signature);
}
- else if (! use_debug_types && AT_ref (a)->die_id.die_symbol)
+ else if (AT_ref (a)->die_id.die_symbol)
fprintf (outfile, "die -> label: %s",
AT_ref (a)->die_id.die_symbol);
else
@@ -5653,13 +5655,17 @@ generate_type_signature (dw_die_ref die, comdat_type_node *type_node)
type node together. */
memcpy (type_node->signature, &checksum[16 - DWARF_TYPE_SIGNATURE_SIZE],
DWARF_TYPE_SIGNATURE_SIZE);
+ die->comdat_type_p = true;
die->die_id.die_type_node = type_node;
type_node->type_die = die;
/* If the DIE is a specification, link its declaration to the type node
as well. */
if (decl != NULL)
-decl->die_id.die_type_node = type_node;
+{
+ decl->comdat_type_p = true;
+ decl->die_id.die_type_node = type_node;
+}
}
/* Do the location expressions look same? */
@@ -5966,7 +5972,7 @@ assign_symbol_names (dw_die_ref die)
{
dw_die_ref c;
- if (is_symbol_die (die))
+ if (is_symbol_die (die) && !die->comdat_type_p)
{
if (comdat_symbol_id)
{
@@ -6300,7 +6306,7 @@ clone_as_declaration (dw_die_ref die)
}
}
- if (die->die_id.die_type_node)
+ if (die->comdat_type_p)
add_AT_die_ref (clone, DW_AT_signature, die);
add_AT_flag (clone, DW_AT_declaration, 1);
@@ -6335,6 +6341,7 @@ copy_declaration_context (dw_die_ref unit, dw_die_ref die)
/* Copy the type node pointer from the new DIE to the original
declaration DIE so we can forward references later. */
+ decl->comdat_type_p = true;
decl->die_id.die_type_node = die->die_id.die_type_node;
remove_AT (die, DW_AT_specification);
@@ -6469,6 +6476,7 @@ remove_child_or_replace_with_skeleton (dw_die_ref unit, dw_die_ref child,
remove_child_with_prev (child, prev);
else
{
+ skeleton->comdat_type_p = true;
skeleton->die_id.die_type_node = child->die_id.die_type_node;
/* If the original DIE was a specification, we need to put
@@ -6684,11 +6692,10 @@ copy_decls_walk (dw_die_ref unit, dw_die_ref die, htab_t decl_table)
if (AT_class (a) == dw_val_class_die_ref)
{
dw_die_ref targ = AT_ref (a);
- comdat_type_node_ref type_node = targ->die_id.die_type_node;
void **slot;
struct decl_table_entry *entry;
- i
Re: Backported r187026 from branches/google/gcc-4_6 (issue 6148044)
LGTM On Wed, May 2, 2012 at 11:24 AM, wrote: > On 2012/05/01 22:51:22, jingyu wrote: >> >> 1) Please add an description entry to libgcc/ChangeLog.google-4_6 > > > Done. > > > >> 2) Your gcc/ChangeLog.google-4_6 change reverts someone else's change. > > Please >> >> update it and also update the time of your entry. > > > Done. > > > >> 3) Please list in the Description field what tests you have done. > > > Done. > > >> Thanks, >> Jing > > >> On 2012/05/01 22:40:12, asharif wrote: >> > +carrot@ > > > > > http://codereview.appspot.com/6148044/
Re: RFC: PATCH to correct the scopes of various types
On 05/02/2012 01:08 PM, Jason Merrill wrote: * dwarf2out.c (modified_type_die): Use scope_die_for. (gen_type_die_with_usage, dwarf2out_finish): Likewise. (uses_local_type_r, uses_local_type): New. (scope_die_for): Keep a type that uses a local type in local scope. Use get_context_die for namespace and type scope. Makes sense. r~
Re: Fix find_moveable_pseudos, PR52997
Bernd Schmidt wrote: > On 04/27/2012 06:25 PM, Ulrich Weigand wrote: > > Bernd Schmidt wrote: > > > >> We're creating new pseudos, and while we're resizing some data > >> structures, we aren't doing it for everything. > > > >> @@ -3983,7 +3983,8 @@ find_moveable_pseudos (void) > >> > >> last_moveable_pseudo = max_reg_num (); > >> > >> - fix_reg_equiv_init(); > >> + fix_reg_equiv_init (); > >> + resize_reg_info (); > >> regstat_free_n_sets_and_refs (); > >> regstat_free_ri (); > >> regstat_init_n_sets_and_refs (); > > > > This causes a bootstrap failure on s390 when enabling > > -fsched-pressure -fsched-pressure-algorithm=model by default > > (not sure why this doesn't show up without that change). > > > > The problem is that resize_reg_info only resizes the data > > structure, but leaves it uninitialized. > > Argh. Something like this maybe (currently testing on i686-linux, ok if > it passes?) This has fixed the problem I was seeing, thanks! Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
[commit] Enable -fsched-pressure by default on s390
Richard Sandiford wrote:
> "Ulrich Weigand" writes:
> > Richard Sandiford wrote:
> >> Vladimir Makarov writes:
> >> > Taking your results for S390 and ARM with Neon into account, I guess it
> >> > should be included and probably made by default for these 2 targets (for
> >> > sure for s390).
> >>
> >> OK, thanks to both of you.
> >>
> >> Ulrich and Andreas: would you be happy for s390 to use this by default?
> >> I'll update the patch and install if so.
> >
> > I've talked to Andreas, and we agree that s390 should use this as default.
> > If you install the base patch, we'll do the back-end change accordingly.
> > (I'll also work with Ramana to enable it on ARM where it makes sense,
> > probably when targeting Cortex-A cores.)
>
> OK, installed after bootstrapping & regression-testing on
> x86_64-linux-gnu, both as normal and with:
Thanks! I've now checked in the following patch to enable
-fsched-pressure -fsched-pressure-algorithm=model by default on s390.
(The different schedule uncovered a problem with a missing "volatile"
in an asm statement in a s390-specific test case ...)
Tested with no regressions on s390x-ibm-linux.
Bye,
Ulrich
2012-05-02 Ulrich Weigand
gcc/
* common/config/s390/s390-common.c (s390_option_optimization_table):
Enable -fsched-pressure using -fsched-pressure-algorithm=model by
default when optimizing.
gcc/testsuite/
* gcc.target/s390/20030123-1.c: Add missing "volatile".
Index: gcc/testsuite/gcc.target/s390/20030123-1.c
===
--- gcc/testsuite/gcc.target/s390/20030123-1.c (revision 187042)
+++ gcc/testsuite/gcc.target/s390/20030123-1.c (working copy)
@@ -12,7 +12,7 @@
char *p = alloca (4096);
long idx;
- asm ("" : "=r" (idx) : : "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
"12");
+ asm volatile ("" : "=r" (idx) : : "1", "2", "3", "4", "5", "6", "7", "8",
"9", "10", "12");
func (p + idx + 1);
}
Index: gcc/common/config/s390/s390-common.c
===
--- gcc/common/config/s390/s390-common.c(revision 187042)
+++ gcc/common/config/s390/s390-common.c(working copy)
@@ -51,6 +51,12 @@
{
{ OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },
+/* Enable -fsched-pressure using -fsched-pressure-algorithm=model
+ by default when optimizing. */
+{ OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
+{ OPT_LEVELS_1_PLUS, OPT_fsched_pressure_algorithm_,
+ NULL, SCHED_PRESSURE_MODEL },
+
/* ??? There are apparently still problems with -fcaller-saves. */
{ OPT_LEVELS_ALL, OPT_fcaller_saves, NULL, 0 },
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: RFC: PATCH to allow symbolic and sig8 DWARF references in the same compile
> Here's my patch to allow -feliminate-dwarf2-dups and -fdebug-types-section > to coexist, so that I can then use symbolic references for my function > COMDAT work. Does this look reasonable to you? Yep, looks good to me. -cary
Re: [patch] For alpha-vms, unset flag_jump_tables if flag_pic is nonzero
On 05/02/2012 12:26 PM, Steven Bosscher wrote: * config/alpha/vms.h (SUBTARGET_OVERRIDE_OPTIONS): For pic code, unset flag_jump_tables. * stmt.c (expand_case): Remove special flag_pic case conditional on ASM_OUTPUT_ADDR_DIFF_ELT not being defined. Ok. I had a brief look at the vms file format. It looks to me as if the lack of A_O_A_D_E is a defect in gas; it ought to be representable in the object file as a difference of two psect+offset addresses. r~
[i386] access subvectors
Hello,
I definitely don't expect the attached patch to be accepted, but I would
like some advice on the direction to go, and a patch that passes the
testsuite and does the optimization I want on a couple testcases seems
like it may help start the conversation. This is the first time I even
look at .md files...
The goal is to optimize: v8sf x; v4sf y=*(v4sf*)&x; so the compiler
doesn't copy x to memory (yes, I know there is an intrinsic to do that).
If I understood Richard Guenther's comment in the PR, it can be optimized
in the back-end. The only way I found to place this kind of transformation
is with define_peephole2. And I couldn't figure out how to test if 2
memory operands correspond to the same address, with different types (so
match_dup is unhappy), and for some reason the XEXP(*,0) comparison said
yes on my test and no when using an unrelated piece of memory, but it
looks like a nonsense test that is just lucky on a couple trivial
examples.
Any help?
2012-05-02 Marc Glisse
PR target/53101
gcc/
* config/i386/sse.md: New peephole2 for subvectors.
gcc/testsuite/
* gcc.target/i386/pr53101.c: New test.
--
Marc GlisseIndex: gcc/testsuite/gcc.target/i386/pr53101.c
===
--- gcc/testsuite/gcc.target/i386/pr53101.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr53101.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx" } */
+
+typedef double v2df __attribute__ ((vector_size (16)));
+typedef double v4df __attribute__ ((vector_size (32)));
+typedef double v4si __attribute__ ((vector_size (16)));
+typedef double v8si __attribute__ ((vector_size (32)));
+
+v4si
+avx_extract_v4si (v8si x)
+{
+ return *(v4si*)&x;
+}
+
+v2df
+avx_extract_v2df (v4df x __attribute((unused)), v4df y)
+{
+ return *(v2df*)&y;
+}
+
+/* { dg-final { scan-assembler-not "movdq" } } */
+/* { dg-final { scan-assembler-times "movapd" 1 } } */
Property changes on: gcc/testsuite/gcc.target/i386/pr53101.c
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Index: gcc/config/i386/sse.md
===
--- gcc/config/i386/sse.md (revision 187012)
+++ gcc/config/i386/sse.md (working copy)
@@ -4104,10 +4104,34 @@
emit_move_insn (operands[0], adjust_address (operands[1], SFmode, i*4));
DONE;
})
+;; This is how we receive accesses to the first half of a vector.
+(define_peephole2
+ [(set (match_operand:VI8F_256 3 "memory_operand")
+(match_operand:VI8F_256 1 "register_operand"))
+ (set (match_operand: 0 "register_operand")
+(match_operand: 2 "memory_operand"))]
+ "TARGET_AVX && rtx_equal_p (XEXP (operands[2], 0), XEXP (operands[3], 0))"
+ [(set (match_dup 0)
+(vec_select: (match_dup 1)
+ (parallel [(const_int 0) (const_int
1)])))]
+)
+
+(define_peephole2
+ [(set (match_operand:VI4F_256 3 "memory_operand")
+(match_operand:VI4F_256 1 "register_operand"))
+ (set (match_operand: 0 "register_operand")
+(match_operand: 2 "memory_operand"))]
+ "TARGET_AVX && rtx_equal_p (XEXP (operands[2], 0), XEXP (operands[3], 0))"
+ [(set (match_dup 0)
+(vec_select: (match_dup 1)
+ (parallel [(const_int 0) (const_int 1)
+ (const_int 2) (const_int 3)])))]
+)
+
(define_expand "avx_vextractf128"
[(match_operand: 0 "nonimmediate_operand")
(match_operand:V_256 1 "register_operand")
(match_operand:SI 2 "const_0_to_1_operand")]
"TARGET_AVX"
Re: [Patch, testsuite] missing -ftrack-macro-expansion=0 option in gcc.dg/builtin-stringop-chk-1.c
On Wed, May 2, 2012 at 1:21 PM, Greta Yorsh wrote: > The test gcc.dg/builtin-stringop-chk-1.c fails on arm-none-eabi because the > command line option -ftrack-macro-expansion=0 is missing. > > This command-line option has recently been added to dg-options directive in > this test, but for arm targets the first dg-options directive in the test is > overwritten by a second dg-options that does not contain > -ftrack-macro-expansion=0. > > This patch replaces the second dg-options directive with > dg-additional-options. Fixed test passes on qemu. > > OK for trunk? OK. -- Gaby
[v3] update outdated allocator docs
Several places in the manual still imply mt_allocator is the default or refer to GLIBCXX_FORCE_NEW as affecting the default allocator, which hasn't been true since GCC 3.3! * doc/xml/faq.xml: Update outdated allocator documentation. * doc/xml/manual/allocator.xml: Likewise. * doc/xml/manual/debug.xml: Likewise. * doc/xml/manual/evolution.xml: Likewise. * doc/xml/manual/using.xml: Likewise. Tested x86_64-linux, committed to trunk. commit 54ea46758e35adc8b42ee35dafdf0b43e9980104 Author: Jonathan Wakely Date: Thu May 3 00:12:48 2012 +0100 * doc/xml/faq.xml: Update outdated allocator documentation. * doc/xml/manual/allocator.xml: Likewise. * doc/xml/manual/debug.xml: Likewise. * doc/xml/manual/evolution.xml: Likewise. * doc/xml/manual/using.xml: Likewise. diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml index e2cf49a..1408bd2 100644 --- a/libstdc++-v3/doc/xml/faq.xml +++ b/libstdc++-v3/doc/xml/faq.xml @@ -935,8 +935,8 @@ A few people have reported that the standard containers appear to leak memory when tested with memory checkers such as http://www.w3.org/1999/xlink"; xlink:href="http://valgrind.org/";>valgrind. -The library's default allocators keep free memory in a pool -for later reuse, rather than returning it to the OS. Although +Under some configurations the library's allocators keep free memory in a +pool for later reuse, rather than returning it to the OS. Although this memory is always reachable by the library and is never lost, memory debugging tools can report it as a leak. If you want to test the library for memory leaks please read diff --git a/libstdc++-v3/doc/xml/manual/allocator.xml b/libstdc++-v3/doc/xml/manual/allocator.xml index 55dc808..911aaf5 100644 --- a/libstdc++-v3/doc/xml/manual/allocator.xml +++ b/libstdc++-v3/doc/xml/manual/allocator.xml @@ -103,7 +103,7 @@ implements the simple operator new and operator delete semantics, while __gnu_cxx::malloc_allocator implements much the same thing, only with the C language functions -std::malloc and free. +std::malloc and std::free. @@ -236,12 +236,12 @@ In use, allocator may allocate and - deallocate using implementation-specified strategies and - heuristics. Because of this, every call to an allocator object's + deallocate using implementation-specific strategies and + heuristics. Because of this, a given call to an allocator object's allocate member function may not actually - call the global operator new. This situation is also duplicated - for calls to the deallocate member - function. + call the global operator new and a given call to + to the deallocate member function may not + call operator delete. @@ -250,7 +250,7 @@ In particular, this can make debugging memory errors more - difficult, especially when using third party tools like valgrind or + difficult, especially when using third-party tools like valgrind or debug versions of new. @@ -258,9 +258,9 @@ There are various ways to solve this problem. One would be to use a custom allocator that just called operators new and delete - directly, for every allocation. (See + directly, for every allocation. (See the default allocator, include/ext/new_allocator.h, for instance.) - However, that option would involve changing source code to use + However, that option may involve changing source code to use a non-default allocator. Another option is to force the default allocator to remove caching and pools, and to directly allocate with every call of allocate and @@ -271,8 +271,8 @@ - To globally disable memory caching within the library for the - default allocator, merely set + To globally disable memory caching within the library for some of + the optional non-default allocators, merely set GLIBCXX_FORCE_NEW (with any value) in the system's environment before running the program. If your program crashes with GLIBCXX_FORCE_NEW in the @@ -472,7 +472,8 @@ A high-performance fixed-size allocator with exponentially-increasing allocations. It has its own -documentation, found here. +chapter + in the documentation. @@ -483,7 +484,8 @@ A high-performance allocator that uses a bit-map to keep track of the used and unused memory locations. It has its own -documentation, found here. +chapter + in the documentation. diff --git a/libstdc++-v3/doc/xml/manual/debug.xml b/libstdc++-v3/doc/xml/manual/debug.xml index 0a24c96..7a984bb 100644 --- a/libstdc++-v3/doc/xml/manual/debug.xml +++ b/libstdc++-v3/doc/xml/manual/debug.xml @@ -116,13 +116,13 @@ thing of gre
Re: [PATCH] Fix overzealous DSE on sparc
From: Richard Sandiford Date: Wed, 02 May 2012 20:37:58 +0100 > I think the problem is in the way sparc.c:emit_soft_tfmode_libcall > reuses existing MEMs when passing arguments on the stack: > > if (GET_CODE (this_arg) == MEM > && ! force_stack_temp) > this_arg = XEXP (this_arg, 0); > > -ffloat-store forces "a" and "b" to be stored in their argument slots, > and emit_soft_tfmode_libcall then passes the address of these incoming > argument slots to the libcall. But "a" and "b" don't escape, so DSE > thinks that the call can't read them. I'm fine with adjusting how we emit libcalls to better show the compiler what's going on. Can you suggest a way that we can mark these MEMs so that the rest of the compiler will know that these values can in fact escape?
[C++ Patch] PR 53186
Hi,
Vincenzo reported today that the work done by Roberto on devirtualizing
final methods, doesn't cover operators (of all sorts). Thus I prepared
the below, which passes the testsuite on x86_64-linux.
Is it Ok?
Thanks,
Paolo.
/
/cp
2012-05-03 Paolo Carlini
PR c++/53186
* call.c (build_over_call_maybe_devirtualize): New.
(build_op_call_1, build_new_op_1, convert_like_real): Use it.
/testsuite
2012-05-03 Paolo Carlini
PR c++/53186
* g++.dg/other/final2.C: New.
Index: cp/call.c
===
--- cp/call.c (revision 187058)
+++ cp/call.c (working copy)
@@ -4031,6 +4031,26 @@ build_operator_new_call (tree fnname, VEC(tree,gc)
return build_over_call (cand, LOOKUP_NORMAL, complain);
}
+/* Variant of build_over_call which checks if the call can be
+ devirtualized. */
+
+static tree
+build_over_call_maybe_devirtualize (struct z_candidate *cand,
+ tsubst_flags_t complain)
+{
+ tree fn = cand->fn;
+ tree fntype = TREE_TYPE (fn);
+ int flags = LOOKUP_NORMAL;
+
+ if (DECL_FINAL_P (fn)
+ || (TREE_CODE (fntype) == METHOD_TYPE
+ && CLASSTYPE_FINAL (TYPE_METHOD_BASETYPE (fntype
+/* We can devirtualize. */
+flags |= LOOKUP_NONVIRTUAL;
+
+ return build_over_call (cand, flags, complain);
+}
+
/* Build a new call to operator(). This may change ARGS. */
static tree
@@ -4149,7 +4169,7 @@ build_op_call_1 (tree obj, VEC(tree,gc) **args, ts
DECL_NAME here. */
else if (TREE_CODE (cand->fn) == FUNCTION_DECL
&& DECL_OVERLOADED_OPERATOR_P (cand->fn) == CALL_EXPR)
- result = build_over_call (cand, LOOKUP_NORMAL, complain);
+ result = build_over_call_maybe_devirtualize (cand, complain);
else
{
obj = convert_like_with_context (cand->convs[0], obj, cand->fn, -1,
@@ -5163,7 +5183,7 @@ build_new_op_1 (enum tree_code code, int flags, tr
if (resolve_args (arglist, complain) == NULL)
result = error_mark_node;
else
- result = build_over_call (cand, LOOKUP_NORMAL, complain);
+ result = build_over_call_maybe_devirtualize (cand, complain);
}
else
{
@@ -5755,7 +5775,10 @@ convert_like_real (conversion *convs, tree expr, t
for (i = 0; i < cand->num_convs; ++i)
cand->convs[i]->user_conv_p = true;
- expr = build_over_call (cand, LOOKUP_NORMAL, complain);
+ if (TREE_CODE (convfn) == FUNCTION_DECL)
+ expr = build_over_call_maybe_devirtualize (cand, complain);
+ else
+ expr = build_over_call (cand, LOOKUP_NORMAL, complain);
/* If this is a constructor or a function returning an aggr type,
we need to build up a TARGET_EXPR. */
Index: testsuite/g++.dg/other/final2.C
===
--- testsuite/g++.dg/other/final2.C (revision 0)
+++ testsuite/g++.dg/other/final2.C (revision 0)
@@ -0,0 +1,27 @@
+// PR c++/53186
+// { dg-options "-fdump-tree-original -std=c++11" }
+
+struct F1
+{
+ virtual void operator()() final;
+ virtual operator int() final;
+ virtual int operator++() final;
+};
+
+struct F2 final
+{
+ virtual void operator()();
+ virtual operator int();
+ virtual int operator++();
+};
+
+void fooF1(F1& a) { a(); int m = a; ++a; }
+void fooF2(F2& a) { a(); int m = a; ++a; }
+
+// { dg-final { scan-tree-dump-times "F1::operator\\(\\)" 1 "original" } }
+// { dg-final { scan-tree-dump-times "F1::operator int" 1 "original" } }
+// { dg-final { scan-tree-dump-times "F1::operator\\+\\+" 1 "original" } }
+// { dg-final { scan-tree-dump-times "F2::operator\\(\\)" 1 "original" } }
+// { dg-final { scan-tree-dump-times "F2::operator int" 1 "original" } }
+// { dg-final { scan-tree-dump-times "F2::operator\\+\\+" 1 "original" } }
+// { dg-final { cleanup-tree-dump "original" } }
Re: [PATCH] Fix overzealous DSE on sparc
From: Richard Sandiford Date: Wed, 02 May 2012 20:37:58 +0100 > I think the DSE assuption is fair though. If you reuse MEMs like this, > then they're no longer just serving the purpose described by MEM_EXPR. I think what Sparc does is fair, so if you are going to suggest that I re-pop these values into new stack slots I'm going to have a hard time swallowing that. In fact, using the incoming argument slots when passing outgoing arguments by reference is exactly what I want the sparc backend to be doing. Furthermore, in the future, I'd like the compiler to be able to use these argument slots when stack temporaries are necessary since every sparc stack frame has to allocate 6 argument slots even if no arguments are passed to the function. This argument slot re-use is a rather common optimization in hand written sparc assembler because this allows us to avoid having to allocate a register window and a stack frame at all, and thus end up also with a leaf procedure even when we need stack temporaries.
RE: [PATCH, reload] Fix bug pr52804, RELOAD pass reloads wrong register on ARM for cortex-m0
> -Original Message- > From: Ulrich Weigand [mailto:uweig...@de.ibm.com] > Sent: Thursday, May 03, 2012 12:05 AM > To: Bin Cheng > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH, reload] Fix bug pr52804, RELOAD pass reloads wrong > register on ARM for cortex-m0 > > Bin Cheng wrote: > > > In short, I think the confliction of reloads with type > > RELOAD_FOR_INPADDR_ADDRESS and type RELOAD_FOR_INPUT_ADDRESS should be > > handled in "reload_reg_reaches_end_p". > > Also I think RELOAD_FOR_OUTPUT_ADDRESS/RELOAD_FOR_OUTADDR_ADDRESS have > > the issue symmetrically, though I have no test case for it. > > Yes, I agree with your reasoning here. This looks like an oversight. > > > PR target/52804 > > * reload1.c (reload_reg_reaches_end_p): Check whether successor > > reload with > > type RELOAD_FOR_INPUT_ADDRESS kills reload register of current one > > with type > > RELOAD_FOR_INPADDR_ADDRESS. > > This is OK. (You also ought to mention the RELOAD_FOR_OUTADDR_ADDRESS part of > the change in the ChangeLog.) Thanks for reviewing, I modified the ChangeLog. Is it ok for trunk and 4.7? I am not sure whether this can be treated as a regression in 4.7 branch since PR52804 has not been confirmed yet. 2012-05-03 Bin Cheng PR target/52804 * reload1.c (reload_reg_reaches_end_p): Check whether successor reload with type RELOAD_FOR_INPUT_ADDRESS kills reload register of current one with type RELOAD_FOR_INPADDR_ADDRESS. Same stands for RELOAD_FOR_OUTPUT_ADDRESS and RELOAD_FOR_OUTADDR_ADDRESS.
Restore bootstrap (PR53197)
Hi,
my gimple_seq reshuffling broke boostrap on some machines. In particular
on those for which contrib/compare-debug works, meaning that
bootstrap-debug is selected as default BUILD_CONFIG (none of my machines
pass the respective configure.ac test, and hence I wasn't seeing the
problem anywhere). Thanks for Jonathan for access to a breaking machine
that set me on the right track.
The things is, that my patch causes different code to be emitted depending
on -g or not -g (or -gtoggle for stage2, which is what the bootstrap-debug
config is doing), when DSE wants to remove some stores. It walks the
sequence incorrectly, potentially with a stale iterator. This was
harmless before, but isn't anymore for backward walks due to the cyclic
structure of the prev links. The effect is that once the last statement
is removed and gsi_prev is called on the original (now stale) iterator
then gsi_end_p will be true, even if there are statement before the just
removed one.
Hence with -g (where the last stmt is a DEBUG one, which isn't removed)
all dead stores were removed in a certain block, whereas with -g0 (where
the store was the last stmt) only that last stmt was removed.
So, do the same as most other backward walkers that potentially remove
last statements (e.g. tree-cfg.c) do and update the iterator instead of a
copy, as well as reset to the end of sequence in case we removed the last
one.
I checked that this patch restores bootstrap when configured with
--with-build-config=bootstrap-debug, but only for the C language. The
miscomparing files in the bug report are all in libbackend.a, so there
shouldn't be more coming with more languages.
In order not to leave the tree broken for much longer I've committed the
below patch as r187074. A full regstrap is running, but I won't see the
results until in a few hours.
Ciao,
Michael.
PR bootstrap/53197
* tree-ssa-dse.c (dse_optimize_stmt): Take pointer to
iterator.
(dse_enter_block): Properly iterate the whole sequence even
if the last statement was removed.
Index: tree-ssa-dse.c
===
--- tree-ssa-dse.c (revision 187053)
+++ tree-ssa-dse.c (working copy)
@@ -199,9 +199,9 @@ dse_possible_dead_store_p (gimple stmt,
post dominates the first store, then the first store is dead. */
static void
-dse_optimize_stmt (gimple_stmt_iterator gsi)
+dse_optimize_stmt (gimple_stmt_iterator *gsi)
{
- gimple stmt = gsi_stmt (gsi);
+ gimple stmt = gsi_stmt (*gsi);
/* If this statement has no virtual defs, then there is nothing
to do. */
@@ -252,7 +252,7 @@ dse_optimize_stmt (gimple_stmt_iterator
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file, " Deleted dead store '");
- print_gimple_stmt (dump_file, gsi_stmt (gsi), dump_flags, 0);
+ print_gimple_stmt (dump_file, gsi_stmt (*gsi), dump_flags, 0);
fprintf (dump_file, "'\n");
}
@@ -261,7 +261,7 @@ dse_optimize_stmt (gimple_stmt_iterator
/* Remove the dead store. */
bb = gimple_bb (stmt);
- if (gsi_remove (&gsi, true))
+ if (gsi_remove (gsi, true))
bitmap_set_bit (need_eh_cleanup, bb->index);
/* And release any SSA_NAMEs set in this statement back to the
@@ -277,8 +277,14 @@ dse_enter_block (struct dom_walk_data *w
{
gimple_stmt_iterator gsi;
- for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi))
-dse_optimize_stmt (gsi);
+ for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi);)
+{
+ dse_optimize_stmt (&gsi);
+ if (gsi_end_p (gsi))
+ gsi = gsi_last_bb (bb);
+ else
+ gsi_prev (&gsi);
+}
}
/* Main entry point. */
RE: [PING] iwMMXt patches
> From: Matt Turner [mailto:matts...@gmail.com] > To: Xinyu Qi > Cc: Ramana Radhakrishnan; GCC Patches > Subject: Re: [PING] iwMMXt patches > > On Tue, Apr 17, 2012 at 4:17 PM, Matt Turner wrote: > > Are these patches ready to go in? It looks like they were ack'd. > > > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01815.html > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01817.html > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01816.html > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01818.html > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01819.html > > > > We (OLPC) will need these patches for reasonable iwMMXt performance > > and the ability to use VFP and iwMMXt together. > > > > Thanks, > > Matt > > Xinyu, > > With these patches I don't see a new -mcpu flag. Isn't a tune/cpu flag > the normal way to activate this code? > > Other .md files have statements like (eq_attr "tune" "cortexa8"), but > I don't see how to turn on the marvell-f-iwmmxt attribute, ie (eq_attr > "marvell_f_iwmmxt" "yes"). > > Please let me know. > > Thanks, > Matt Hi Matt, I updated the patches several months ago by following the review opinions form Richard Earnshaw [richard.earns...@arm.com] (unfortunately, no further feedback) The newest patches are http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01787.html http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01788.html http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01789.html http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01786.html http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01599.html The main discussion is in http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01786.html No new -mcpu flag is introduced in the patches. You can simply turn on marvell-f-iwmmxt by -mcpu=iwmmxt2(or -march=iwmmxt2). (Of course it is odd to treat the "iwmmxt2" as a name of cpu) Thanks, Xinyu
