Re: extend fwprop optimization
On Sun, Mar 17, 2013 at 12:15 AM, Wei Mi wrote: > Hi, > > On Sat, Mar 16, 2013 at 3:48 PM, Steven Bosscher > wrote: >> On Tue, Mar 12, 2013 at 8:18 AM, Wei Mi wrote: >>> For the motivational case, I need insn splitting to get the cost >>> right. insn splitting is not very intrusive. All I need is to call >>> split_insns func. >> >> It may not look very intrusive, but there's a lot happening in the >> back ground. You're creating a lot of new RTL, and then just throw it >> away again. You fake the compiler into thinking you're much deeper in >> the pipeline than you really are. You're assuming there are no >> side-effects other than that some insn gets split, but there are back >> ends where splitters may have side-effects. > > Ok, then I will remove the split_insns call. > >> >> Even though I've asked twice now, you still have not explained this >> motivational case, except to say that there is one. *What* are you >> trying to do, *what* is not happening without the splits, and *what* >> happens if you split. Only if you explain that in a lot more detail >> than "I have a motivational case" then we can look into what is a >> proper solution. > > :-). Sorry, I didn't say it clearly. The motivational case is the one > mentioned in the following posts (split_insns changes a << (b & 63) to > a << b). > http://gcc.gnu.org/ml/gcc/2013-01/msg00181.html > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01144.html > > If I remove the split_insns call and related cost estimation > adjustment, the fwprop 18-->22 and 18-->23 will punt, because fwprop > here looks like a reverse process of cse, the total cost after fwprop > change is increased. > > Def insn 18: > Use insn 23 > Use insn 22 > > If we include the split_insns cost estimation adjustment. > extra benefit by removing def insn 18 = 5 > change[0]: benefit = 0, verified - ok // The cost of insn 22 will > not change after fwprop + insn splitting. > change[1]: benefit = 0, verified - ok // The insn 23 is the same with insn > 22 > Total benefit is 5, fwprop will go on. > > If we remove the split_insns cost estimation adjustment. > extra benefit by removing def insn 18 = 5 > change[0]: benefit = -4, verified - ok // The costs of insn 22 and > insn 23 will increase after fwprop. > change[1]: benefit = -4, verified - ok // The insn 23 is the same > with insn 22 > Total benefit is -3, fwprop will punt. > > How about adding the (a << (b&63) ==> a << b) transformation in > simplify_binary_operation_1, becuase (a << (b&63) ==> a << b) is a > kind of architecture specific expr simplification? Then fwprop could > do the propagation as I expect. > >> >> The problem with some of the splitters is that they exist to break up >> RTL from 'expand' to initially keep some pattern together to allow the >> code transformation passes to handle the pattern as one instruction. >> This made sense when RTL was the only intermediate representation and >> splitting too early would inhibit some optimizations. But I would >> expect most (if not all) such cases to be less relevant because of the >> GIMPLE middle-end work. The only splitters you can trigger are the >> pre-reload splitters (all the reload_completed conditions obviously >> can't trigger if you're splitting from fwprop). Perhaps those >> splitters can/should run earlier, or be made obsolete by expanding >> directly to the post-splitting insns. >> >> Unfortunately, it's not possible to tell for your case, because you >> haven't explained it yet... >> >> >>> So how about keep split_insns and remove peephole in the cost estimation >>> func? >> >> I'd strongly oppose this. I do not believe this is necessary, and I >> think it's conceptually wrong. >> >> What happens if you propagate into an insn that uses the same register twice? Will the DU chains still be valid (I don't think that's guaranteed)? >>> >>> I think the DU chains still be valid. If propagate into the insn that >>> uses the same register twice, the two uses will be replaced when the >>> first use is seen (propagate_rtx_1 will propagate all the occurrances >>> of the same reg in the use insn). When the second use is seen, the >>> df_use and use insn in its insn_info are still available. >>> forward_propagate_into will early return after check reg_mentioned_p >>> (DF_REF_REG (use), parent) and find out no reg is used any more. >> >> With reg_mentioned_p you cannot verify that the DF_REF_LOC of USE is >> still valid. > > I think DF_REF_LOC of USE may be invalid if dangling rtx will be > recycled by garbage collection very soon (I don't know when GC will > happen). Although DF_REF_LOC of USE maybe invalid, the early return in > forward_propagate_into ensure it will not cause any correctness > problem. > >> >> In any case, returning to the RD problem for DU/UD chains is probably >> a good idea, now that RD is not such a hog anymore. In effect fwprop.c >> would return to what it looked like before the patch of r149010. > >
[patch, fortran, 4.9] Improve efficiency of array constructor operators
Hello world,
this patch finally makes the idiom
if (any([a,b,c] < eps)) then
equivalent to
if (a
PR fortran/55806
* frontend-passes.c (optimize_code): Keep track of
current code to make code insertion possible.
(combine_array_constructor): New function.
(optimize_op): Call it.
2013-03-17 Thomas Koenig
PR fortran/55806
* gfortran.dg/array_constructor_43.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 195319)
+++ frontend-passes.c (Arbeitskopie)
@@ -135,6 +135,10 @@ optimize_code (gfc_code **c, int *walk_subtrees AT
else
count_arglist = 0;
+ current_code = c;
+ inserted_block = NULL;
+ changed_statement = NULL;
+
if (op == EXEC_ASSIGN)
optimize_assignment (*c);
return 0;
@@ -991,13 +995,92 @@ optimize_lexical_comparison (gfc_expr *e)
return false;
}
+/* Combine stuff like [a]>b into [a>b], for easier optimization later. Do not
+ do CHARACTER because of possible pessimization involving character lengths. */
+
+static bool
+combine_array_constructor (gfc_expr *e)
+{
+
+ gfc_expr *op1, *op2; /* Shut up warnings. */
+ gfc_expr *scalar;
+ gfc_expr *new_expr;
+ gfc_constructor *c;
+ gfc_constructor_base oldbase, newbase;
+ bool scalar_first;
+
+ /* Array constructors have rank one. */
+ if (e->rank != 1)
+return false;
+
+ op1 = e->value.op.op1;
+ op2 = e->value.op.op2;
+
+ if (op1->expr_type == EXPR_ARRAY && op2->rank == 0)
+scalar_first = false;
+ else if (op2->expr_type == EXPR_ARRAY && op1->rank == 0)
+{
+ scalar_first = true;
+ op1 = e->value.op.op2;
+ op2 = e->value.op.op1;
+}
+ else
+return false;
+
+ if (op2->ts.type == BT_CHARACTER)
+return false;
+
+ if (op2->expr_type == EXPR_CONSTANT)
+scalar = gfc_copy_expr (op2);
+ else
+scalar = create_var (gfc_copy_expr (op2));
+
+ oldbase = op1->value.constructor;
+ newbase = NULL;
+ e->expr_type = EXPR_ARRAY;
+
+ for (c = gfc_constructor_first (oldbase); c;
+ c = gfc_constructor_next (c))
+{
+ new_expr = gfc_get_expr ();
+ new_expr->ts = e->ts;
+ new_expr->expr_type = EXPR_OP;
+ new_expr->rank = c->expr->rank;
+ new_expr->where = c->where;
+ new_expr->value.op.op = e->value.op.op;
+
+ if (scalar_first)
+ {
+ new_expr->value.op.op1 = gfc_copy_expr (scalar);
+ new_expr->value.op.op2 = gfc_copy_expr (c->expr);
+ }
+ else
+ {
+ new_expr->value.op.op1 = gfc_copy_expr (c->expr);
+ new_expr->value.op.op2 = gfc_copy_expr (scalar);
+ }
+
+ gfc_constructor_append_expr (&newbase, new_expr, &(e->where));
+}
+
+ gfc_free_expr (op1);
+ gfc_free_expr (op2);
+
+ e->value.constructor = newbase;
+ return true;
+}
+
/* Recursive optimization of operators. */
static bool
optimize_op (gfc_expr *e)
{
+ bool changed;
+
gfc_intrinsic_op op = e->value.op.op;
+ changed = false;
+
/* Only use new-style comparisons. */
switch(op)
{
@@ -1037,8 +1120,16 @@ optimize_op (gfc_expr *e)
case INTRINSIC_NE:
case INTRINSIC_GT:
case INTRINSIC_LT:
- return optimize_comparison (e, op);
+ changed = optimize_comparison (e, op);
+ /* Fall through */
+ /* Look at array constructors. */
+case INTRINSIC_PLUS:
+case INTRINSIC_MINUS:
+case INTRINSIC_TIMES:
+case INTRINSIC_DIVIDE:
+ return combine_array_constructor (e) || changed;
+
default:
break;
}
! { dg-do compile }
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
program main
implicit none
real :: a,b,c,d
call random_number(a)
call random_number(b)
call random_number(c)
call random_number(d)
if (any ([a,b,c,d] < 0.2)) print *,"foo"
end program main
! { dg-final { scan-tree-dump-times "\\\|\\\|" 3 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
New Swedish PO file for 'gcc' (version 4.8-b20130224)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-4.8-b20130224.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Fix ICE building Mozilla with LTO
Hi,
current mainline (as well as release branch) dies by ICE in
cgraph_mark_address_taken
because we attempt to create reference to inline clone. This happens becuase
of ltrans
propagation for pretty special case from devirtualization missed by WPA but
taken by
constant propagation happening as part of clone creating.
In this case we need to re-create symbol node for the virtual call that we fail
t do so.
It is the same case as in ipa_make_edge_direct_to_target where I added the
necessary code.
This patch is not aesthetically pleasing because I plan to solve the problem
for 4.9
by moving cgraph clones out of symbol table hash, but it is not trivial to do
so and
I hope this form of patch is fine for release branch.
Bootstrapped/regtested x86_64-linux, I will commit it to mainline. Does it seem
OK for
release branch? (it is technically a regression even if I do not have better
testcase
than Mozilla version that does not build with 4.7. It depends heavily on
partitioning
decisions making it hard to reduce).
Honza
* cgraph.h (cgraph_get_create_real_symbol_node): Declare.
* cgraph.c (cgraph_get_create_real_symbol_node): New function.
* cgrpahbuild.c: Use cgraph_get_create_real_symbol_node instead
of cgraph_get_create_node.
* ipa-prop.c (ipa_make_edge_direct_to_target): Likewise.
Index: cgraph.h
===
--- cgraph.h(revision 196601)
+++ cgraph.h(working copy)
@@ -575,6 +575,7 @@
struct cgraph_node * cgraph_create_node (tree);
struct cgraph_node * cgraph_create_empty_node (void);
struct cgraph_node * cgraph_get_create_node (tree);
+struct cgraph_node * cgraph_get_create_real_symbol_node (tree);
struct cgraph_node * cgraph_same_body_alias (struct cgraph_node *, tree, tree);
struct cgraph_node * cgraph_add_thunk (struct cgraph_node *, tree, tree, bool,
HOST_WIDE_INT,
HOST_WIDE_INT, tree, tree);
Index: cgraph.c
===
--- cgraph.c(revision 196601)
+++ cgraph.c(working copy)
@@ -2595,4 +2597,47 @@
FOR_EACH_FUNCTION (node)
verify_cgraph_node (node);
}
+
+/* Create external decl node for DECL.
+ The difference i nbetween cgraph_get_create_node and
+ cgraph_get_create_real_symbol_node is that cgraph_get_create_node
+ may return inline clone, while cgraph_get_create_real_symbol_node
+ will create a new node in this case.
+ FIXME: This function should be removed once clones are put out of decl
+ hash. */
+
+struct cgraph_node *
+cgraph_get_create_real_symbol_node (tree decl)
+{
+ struct cgraph_node *first_clone = cgraph_get_node (decl);
+ struct cgraph_node *node;
+ /* create symbol table node. even if inline clone exists, we can not take
+ it as a target of non-inlined call. */
+ node = cgraph_get_node (decl);
+ if (node && !node->global.inlined_to)
+return node;
+
+ node = cgraph_create_node (decl);
+
+ /* ok, we previously inlined the function, then removed the offline copy and
+ now we want it back for external call. this can happen when
devirtualizing
+ while inlining function called once that happens after extern inlined and
+ virtuals are already removed. in this case introduce the external node
+ and make it available for call. */
+ if (first_clone)
+{
+ first_clone->clone_of = node;
+ node->clones = first_clone;
+ symtab_prevail_in_asm_name_hash ((symtab_node) node);
+ symtab_insert_node_to_hashtable ((symtab_node) node);
+ if (dump_file)
+ fprintf (dump_file, "Introduced new external node "
+"(%s/%i) and turned into root of the clone tree.\n",
+xstrdup (cgraph_node_name (node)), node->uid);
+}
+ else if (dump_file)
+fprintf (dump_file, "Introduced new external node "
+"(%s/%i).\n", xstrdup (cgraph_node_name (node)), node->uid);
+ return node;
+}
#include "gt-cgraph.h"
Index: cgraphbuild.c
===
--- cgraphbuild.c (revision 196601)
+++ cgraphbuild.c (working copy)
@@ -73,7 +73,7 @@
decl = get_base_var (*tp);
if (TREE_CODE (decl) == FUNCTION_DECL)
{
- struct cgraph_node *node = cgraph_get_create_node (decl);
+ struct cgraph_node *node = cgraph_get_create_real_symbol_node (decl);
if (!ctx->only_vars)
cgraph_mark_address_taken_node (node);
ipa_record_reference ((symtab_node)ctx->varpool_node,
@@ -143,7 +143,7 @@
{
struct cgraph_node *per_node;
- per_node = cgraph_get_create_node (DECL_FUNCTION_PERSONALITY
(node->symbol.decl));
+ per_node = cgraph_get_create_real_symbol_node (DECL_FUNCTION_PERSONALITY
(node->symbol.decl));
ipa_record_reference ((symtab_node)node, (symtab_node)per_node,
IPA_REF_ADDR, NULL);
cgraph_mark_address_taken_node (per_node);
}
Fold VEC_COND_EXPR to abs, min, max
Hello,
this patch adds a bit of folding to VEC_COND_EXPR so it is possible to
generate ABS_EXPR and MAX_EXPR for vectors without relying on the
vectorizer. I would have preferred to merge the COND_EXPR and
VEC_COND_EXPR cases, but there are too many things that need fixing first,
so I just copied the most relevant block. Folding from the front-end is
ugly, but that's how the scalar case works, and they can both move to
gimple folding together later.
Bootstrap + testsuite on x86_64-linux-gnu.
2013-03-17 Marc Glisse
gcc/
* fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst.
VEC_COND_EXPR cannot be lvalues.
(fold_ternary_loc) : Call fold_cond_expr_with_comparison.
gcc/cp/
* call.c (build_conditional_expr_1): Fold VEC_COND_EXPR.
gcc/testsuite/
* g++.dg/ext/vector21.C: New testcase.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/ext/vector21.C
===
--- gcc/testsuite/g++.dg/ext/vector21.C (revision 0)
+++ gcc/testsuite/g++.dg/ext/vector21.C (revision 0)
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-gimple" } */
+
+typedef int vec __attribute__ ((vector_size (4 * sizeof (int;
+
+void f1 (vec *x)
+{
+ *x = (*x >= 0) ? *x : -*x;
+}
+void f2 (vec *x)
+{
+ *x = (0 < *x) ? *x : -*x;
+}
+void g1 (vec *x)
+{
+ *x = (*x < 0) ? -*x : *x;
+}
+void g2 (vec *x)
+{
+ *x = (0 > *x) ? -*x : *x;
+}
+void h (vec *x, vec *y)
+{
+ *x = (*x < *y) ? *y : *x;
+}
+void i (vec *x, vec *y)
+{
+ *x = (*x < *y) ? *x : *y;
+}
+void j (vec *x, vec *y)
+{
+ *x = (*x < *y) ? *x : *x;
+}
+
+/* { dg-final { scan-tree-dump-times "ABS_EXPR" 4 "gimple" } } */
+/* { dg-final { scan-tree-dump "MIN_EXPR" "gimple" } } */
+/* { dg-final { scan-tree-dump "MAX_EXPR" "gimple" } } */
+/* { dg-final { scan-tree-dump-not "VEC_COND_EXPR" "gimple" } } */
+/* { dg-final { cleanup-tree-dump "gimple" } } */
Property changes on: gcc/testsuite/g++.dg/ext/vector21.C
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 196748)
+++ gcc/fold-const.c(working copy)
@@ -4625,21 +4625,21 @@ fold_cond_expr_with_comparison (location
A == 0 ? A : 0 is always 0 unless A is -0. Note that
both transformations are correct when A is NaN: A != 0
is then true, and A == 0 is false. */
if (!HONOR_SIGNED_ZEROS (TYPE_MODE (type))
&& integer_zerop (arg01) && integer_zerop (arg2))
{
if (comp_code == NE_EXPR)
return pedantic_non_lvalue_loc (loc, fold_convert_loc (loc, type,
arg1));
else if (comp_code == EQ_EXPR)
- return build_int_cst (type, 0);
+ return build_zero_cst (type);
}
/* Try some transformations of A op B ? A : B.
A == B? A : Bsame as B
A != B? A : Bsame as A
A >= B? A : Bsame as max (A, B)
A > B? A : Bsame as max (B, A)
A <= B? A : Bsame as min (A, B)
A < B? A : Bsame as min (B, A)
@@ -4662,21 +4662,22 @@ fold_cond_expr_with_comparison (location
expressions will be false, so all four give B. The min()
and max() versions would give a NaN instead. */
if (!HONOR_SIGNED_ZEROS (TYPE_MODE (type))
&& operand_equal_for_comparison_p (arg01, arg2, arg00)
/* Avoid these transformations if the COND_EXPR may be used
as an lvalue in the C++ front-end. PR c++/19199. */
&& (in_gimple_form
|| (strcmp (lang_hooks.name, "GNU C++") != 0
&& strcmp (lang_hooks.name, "GNU Objective-C++") != 0)
|| ! maybe_lvalue_p (arg1)
- || ! maybe_lvalue_p (arg2)))
+ || ! maybe_lvalue_p (arg2)
+ || TREE_CODE (TREE_TYPE (arg1)) == VECTOR_TYPE))
{
tree comp_op0 = arg00;
tree comp_op1 = arg01;
tree comp_type = TREE_TYPE (comp_op0);
/* Avoid adding NOP_EXPRs in case this is an lvalue. */
if (TYPE_MAIN_VARIANT (comp_type) == TYPE_MAIN_VARIANT (type))
{
comp_type = type;
comp_op0 = arg1;
@@ -14138,20 +14139,51 @@ fold_ternary_loc (location_t loc, enum t
return NULL_TREE;
case VEC_COND_EXPR:
if (TREE_CODE (arg0) == VECTOR_CST)
{
if (integer_all_onesp (arg0) && !TREE_SIDE_EFFECTS (op2))
return pedantic_non_lvalue_loc (loc, op1);
if (integer_zerop (arg0) && !TREE_SIDE_EFFECTS (op1))
return pedantic_non_lvalue_loc (loc, op2);
}
+ if (operand_equal_p (arg1, op2, 0))
+ return pedantic_omit_one_operand_loc (loc, type, arg1, arg0);
+
+ /* If we have A op B ? A : C, we may be able to convert this to a
+simpler expression, depending on the operation and the values
+of B and C. Signed zeros prevent all of t
[committed] Fix ARM REG_CLASS_NAMES (PR target/56640)
Hi! Committed as obvious to trunk and 4.8 branch. 2013-03-17 Jakub Jelinek PR target/56640 * config/arm/arm.h (REG_CLASS_NAMES): Add "SFP_REG" and "AFP_REG" class names. Remove trailing comma after "ALL_REGS". --- gcc/config/arm/arm.h2013-03-16 08:33:10.789067850 +0100 +++ gcc/config/arm/arm.h2013-03-17 17:20:01.790206592 +0100 @@ -1166,7 +1166,9 @@ enum reg_class "IWMMXT_GR_REGS",\ "CC_REG",\ "VFPCC_REG", \ - "ALL_REGS", \ + "SFP_REG", \ + "AFP_REG", \ + "ALL_REGS" \ } /* Define which registers fit in which classes. Jakub
[v3] libstdc++/55979 (+ notes about 55977)
Hi,
I had a look to these two PRs and, as regards the former, the below
patchlet seems Ok to me even for 4.8.1.
About the latter: a similar change works fine for std::vector and
std::deque, but std::list for example has another problem, which is
already exposed by the v1.emplace_back(i); bit and seems unrelated: we have:
template
struct _List_node : public __detail::_List_node_base
{
///< User's data.
_Tp _M_data;
#if __cplusplus >= 201103L
template
_List_node(_Args&&... __args)
: __detail::_List_node_base(), _M_data(std::forward<_Args>(__args)...)
{ }
#endif
};
together with:
template
_Node*
_M_create_node(_Args&&... __args)
{
_Node* __p = this->_M_get_node();
__try
{
_M_get_Node_allocator().construct(__p,
std::forward<_Args>(__args)...);
}
__catch(...)
{
_M_put_node(__p);
__throw_exception_again;
}
return __p;
}
and this is not Ok in terms of access control, because _List_node tries
to use the constructor, not the allocator (not sure how strict the
Standard is in terms of access control)
I guess we could at least work around the problem by going back to
_M_get_Tp_allocator().construct in _M_create_node (or, better, the
allocator_traits<>::construct equivalent, per the recent fix for 56613;
we would use it on _Tp actually, everywhere) but I don't know if Jon has
already something in his tree for this batch of issues regarding our
base container class / node constructors, or we want to decouple the
issue from 55977, do std::vector and std::deque, which would be trivial
even for 4.8.1, or something else. Suggestions?
Thanks!
Paolo.
//
2013-03-17 Paolo Carlini
PR libstdc++/55979
* include/bits/stl_list.h (_M_initialize_dispatch(_InputIterator,
_InputIterator, __false_type)): Use emplace_back.
* testsuite/23_containers/list/cons/55979.cc: New.
* testsuite/23_containers/list/modifiers/1.h: Adjust.
* testsuite/23_containers/list/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
Index: include/bits/stl_list.h
===
--- include/bits/stl_list.h (revision 196754)
+++ include/bits/stl_list.h (working copy)
@@ -1487,7 +1487,11 @@
__false_type)
{
for (; __first != __last; ++__first)
+#if __cplusplus >= 201103L
+ emplace_back(*__first);
+#else
push_back(*__first);
+#endif
}
// Called by list(n,v,a), and the range constructor when it turns out
Index: testsuite/23_containers/list/cons/55979.cc
===
--- testsuite/23_containers/list/cons/55979.cc (revision 0)
+++ testsuite/23_containers/list/cons/55979.cc (working copy)
@@ -0,0 +1,34 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [v3] libstdc++/55979 (+ notes about 55977)
On 17 March 2013 17:14, Paolo Carlini wrote: > > I guess we could at least work around the problem by going back to > _M_get_Tp_allocator().construct in _M_create_node (or, better, the > allocator_traits<>::construct equivalent, per the recent fix for 56613; we > would use it on _Tp actually, everywhere) but I don't know if Jon has > already something in his tree for this batch of issues regarding our base > container class / node constructors, or we want to decouple the issue from > 55977, do std::vector and std::deque, which would be trivial even for 4.8.1, > or something else. Suggestions? For std::list I'm waiting until we have two separate C++03 and C++11 implementations, then I'll implement allocator support in the C++11 code only, as it will be much easier. To be correct the List_node::_M_data member needs to be replaced with aligned_storage::type, so the _List_node gets constructed with uninitialized memory, then use allocator_traits::construct() to initialize the buffer. (Because that pattern occurs in several places now I'm going to introduce an aligned_buffer<_Tp> template that simplifies it.)
Re: Fix a MinGW warning in libiberty/setenv.c
> Date: Wed, 13 Mar 2013 11:52:48 -0700 > From: Ian Lance Taylor > Cc: gdb-patc...@sourceware.org, d...@redhat.com, gcc-patches@gcc.gnu.org > > On 3/13/13, Eli Zaretskii wrote: > > > > #ifdef __MSVCRT__ > >extern _CRTIMP char *** __cdecl __MINGW_NOTHROW __p__environ(void); > >extern _CRTIMP wchar_t *** __cdecl __MINGW_NOTHROW > > __p__wenviron(void); > > # define _environ (*__p__environ()) > > # define _wenviron (*__p__wenviron()) > > #else /* ! __MSVCRT__ */ > > #endif /* ! __MSVCRT__ */ > > > > #define environ _environ > > Cool. > > >and setenv.c does this: > > > > #ifndef HAVE_ENVIRON_DECL > > extern char **environ; > > #endif > > > >Solution: Add a guard: > > This is OK with a ChangeLog entry. Thanks, committed thusly: 2013-03-17 Eli Zaretskii * setenv.c [!HAVE_ENVIRON_DECL]: Avoid declaring environ if it is a macro, as this causes compiler warnings with MinGW. Index: libiberty/setenv.c === RCS file: /cvs/src/src/libiberty/setenv.c,v retrieving revision 1.10 diff -u -r1.10 setenv.c --- libiberty/setenv.c 3 Feb 2011 07:23:59 - 1.10 +++ libiberty/setenv.c 17 Mar 2013 19:03:07 - @@ -63,8 +63,11 @@ #define __environ environ #ifndef HAVE_ENVIRON_DECL +/* MinGW defines environ to call a function. */ +#ifndef environ extern char **environ; #endif +#endif #undef setenv #undef unsetenv
[PATCH 1/n, i386]: Introduce x64 and nox64 isa attributes; merge FP move patterns
Hello!
Attached patch introduces x64 and nox64 isa attributes. These are used
to merge various TARGET_64BIT only patterns with base patterns. This
patch merges FP move patters, but there will be several follow-up
patches that merge other patterns, too.
2013-03-17 Uros Bizjak
* config/i386/i386.md (isa): Add x64 and nox64.
(enabled): Define x64 for TARGET_64BIT and nox64 for !TARGET_64BIT.
(*pushtf): Enable *roF alternative for x64 isa only.
(*pushxf): Merge with *pushxf_nointeger. Use Yx*r constraint. Set
mode attribute of integer alternatives to DImode for TARGET_64BIT.
(*pushdf): Merge with *pushdf_rex64. Use x64 and nox64 isa attributes.
(*movtf_internal): Merge from *movtf_internal_rex64 and
*movtf_internal_sse. Use x64 and nox64 isa attributes.
(*movxf_internal): Merge with *movxf_internal_rex64. Use x64 and
nox64 isa attributes.
(*movdf_internal): Merge with *movdf_internal_rex64. Use x64 and
nox64 isa attributes.
* config/i386/constraints.md (Yd): Do not set for TARGET_64BIT.
Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} and
committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 196755)
+++ config/i386/i386.md (working copy)
@@ -651,12 +651,14 @@
(define_attr "movu" "0,1" (const_string "0"))
;; Used to control the "enabled" attribute on a per-instruction basis.
-(define_attr "isa" "base,sse2,sse2_noavx,sse3,sse4,sse4_noavx,noavx,avx,
- avx2,noavx2,bmi2,fma4,fma"
+(define_attr "isa" "base,x64,nox64,sse2,sse2_noavx,sse3,sse4,sse4_noavx,
+ noavx,avx,avx2,noavx2,bmi2,fma4,fma"
(const_string "base"))
(define_attr "enabled" ""
- (cond [(eq_attr "isa" "sse2") (symbol_ref "TARGET_SSE2")
+ (cond [(eq_attr "isa" "x64") (symbol_ref "TARGET_64BIT")
+(eq_attr "isa" "nox64") (symbol_ref "!TARGET_64BIT")
+(eq_attr "isa" "sse2") (symbol_ref "TARGET_SSE2")
(eq_attr "isa" "sse2_noavx")
(symbol_ref "TARGET_SSE2 && !TARGET_AVX")
(eq_attr "isa" "sse3") (symbol_ref "TARGET_SSE3")
@@ -2582,16 +2584,17 @@
;; Floating point push instructions.
(define_insn "*pushtf"
- [(set (match_operand:TF 0 "push_operand" "=<,<,<")
- (match_operand:TF 1 "general_no_elim_operand" "x,Fo,*r"))]
- "TARGET_SSE"
+ [(set (match_operand:TF 0 "push_operand" "=<,<")
+ (match_operand:TF 1 "general_no_elim_operand" "x,*roF"))]
+ "TARGET_64BIT || TARGET_SSE"
{
/* This insn should be already split before reg-stack. */
gcc_unreachable ();
}
- [(set_attr "type" "multi")
- (set_attr "unit" "sse,*,*")
- (set_attr "mode" "TF,SI,SI")])
+ [(set_attr "isa" "*,x64")
+ (set_attr "type" "multi")
+ (set_attr "unit" "sse,*")
+ (set_attr "mode" "TF,DI")])
;; %%% Kill this when call knows how to work this out.
(define_split
@@ -2603,34 +2606,22 @@
(define_insn "*pushxf"
[(set (match_operand:XF 0 "push_operand" "=<,<")
- (match_operand:XF 1 "general_no_elim_operand" "f,ro"))]
- "optimize_function_for_speed_p (cfun)"
+ (match_operand:XF 1 "general_no_elim_operand" "f,Yx*roF"))]
+ ""
{
/* This insn should be already split before reg-stack. */
gcc_unreachable ();
}
[(set_attr "type" "multi")
(set_attr "unit" "i387,*")
- (set_attr "mode" "XF,SI")])
+ (set (attr "mode")
+ (cond [(eq_attr "alternative" "1")
+(if_then_else (match_test "TARGET_64BIT")
+ (const_string "DI")
+ (const_string "SI"))
+ ]
+ (const_string "XF")))])
-;; Size of pushxf is 3 (for sub) + 2 (for fstp) + memory operand size.
-;; Size of pushxf using integer instructions is 3+3*memory operand size
-;; Pushing using integer instructions is longer except for constants
-;; and direct memory references (assuming that any given constant is pushed
-;; only once, but this ought to be handled elsewhere).
-
-(define_insn "*pushxf_nointeger"
- [(set (match_operand:XF 0 "push_operand" "=<,<")
- (match_operand:XF 1 "general_no_elim_operand" "f,*rFo"))]
- "optimize_function_for_size_p (cfun)"
-{
- /* This insn should be already split before reg-stack. */
- gcc_unreachable ();
-}
- [(set_attr "type" "multi")
- (set_attr "unit" "i387,*")
- (set_attr "mode" "XF,SI")])
-
;; %%% Kill this when call knows how to work this out.
(define_split
[(set (match_operand:XF 0 "push_operand")
@@ -2640,34 +2631,18 @@
(set (mem:XF (reg:P SP_REG)) (match_dup 1))]
"operands[2] = GEN_INT (-GET_MODE_SIZE (XFmode));")
-(define_insn "*pushdf_rex64"
- [(set (match_operand:DF 0 "push_operand" "=<,<,<")
- (match_operand:DF 1 "general_no_elim_operand" "f,Yd*rFm,x"))]
- "TARGET_64BIT"
-{
- /* This insn should be already split before reg-stack. */
- gcc_unreachable ();
-}
- [(set_attr "type" "multi")
- (set_attr
Re: [patch, fortran, 4.9] Dependency and string length calculation improvements
Thomas, Your test gfortran.dg/dependency_40.f90 does not have depedencies and does not create a temporary (assuming that "-Warray-temporaries" does not miss any) with/without your patch and with gcc4.6, 4.7, and 4.8. 4.5 gives a warning. I have tried a few variants attempting to create a temporary without the patch and none with it, but did not succeeded so far. Cheers, Dominique
Re: C++ PATCH for c++/17232 (abstract class, array and sfinae)
On 03/16/2013 03:38 PM, Jason Merrill wrote: In SFINAE context, we need to instantiate a class so that we can tell whether or not is abstract. Doing this in non-SFINAE context caused problems, so I've made it conditional. But it still causes problems, such as PR 56642. So I've reverted the complete_type change for now. Jason commit 6a0649ab081f34f152517707c84d6be211757029 Author: jason Date: Sun Mar 17 20:32:17 2013 + PR c++/17232 PR c++/56642 * typeck2.c (abstract_virtuals_error_sfinae): Revert complete_type change for now. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@196758 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c index 3bac67c..24b5593 100644 --- a/gcc/cp/typeck2.c +++ b/gcc/cp/typeck2.c @@ -265,10 +265,6 @@ abstract_virtuals_error_sfinae (tree decl, tree type, abstract_class_use use, return 0; type = TYPE_MAIN_VARIANT (type); - /* In SFINAE context, force instantiation. */ - if (!(complain & tf_error)) -complete_type (type); - /* If the type is incomplete, we register it within a hash table, so that we can check again once it is completed. This makes sense only for objects for which we have a declaration or at least a
[PATCH, boehm-gc, AArch64] Add AArch64 support
Hi, this is a backport from gc mainline of the basic AArch64 support (it covers the Linux and bare machine mode). I tested it on the Foundation model with enabling the objc frontend, and passing the testsuite manually (maybe I miss-configured it, but it seems that the boehm-gc testsuite is not cross-environment friendly, as the gctest script looks for the host gcc build tree), and everything is fine, except the thread_leak_test which has a different output than the x86 one: x86 thread_leak_test output Leaked composite object at 0x2ab05fe0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03fa0, appr. length: 40 Leaked composite object at 0x2ab05ec0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x2ab05f20 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03f50, appr. length: 40 Leaked composite object at start: 0x2ab03f78, appr. length: 40 Leaked composite object at 0x2ab05ef0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03fa0, appr. length: 40 Leaked composite object at 0x2ab05e00 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at start: 0x2ab03f78, appr. length: 40 AArch64 thread_leak_test output: Leaked composite object at 0x7f91e14ef0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14fe0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14e00 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14e30 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Leaked composite object at 0x7f91e14fe0 (/work/sources/gcc-fsf/bgc/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:21, sz=4, NORMAL) Regards, Yvan 2013-03-16 Yvan Roux * include/private/gcconfig.h (AARCH64): New macro (defined only if __aarch64__). * include/private/gcconfig.h (mach_type_known): Update comment adding ARM AArch64 target. * include/private/gcconfig.h (NOSYS, mach_type_known, CPP_WORDSZ, MACH_TYPE, ALIGNMENT, HBLKSIZE, OS_TYPE, LINUX_STACKBOTTOM, USE_GENERIC_PUSH_REGS, DYNAMIC_LOADING, DATASTART, DATAEND, STACKBOTTOM): Define for AArch64. boehm-gc-aarch64.patch Description: Binary data
Re: C++ PATCH for c++/54359 ('this' in trailing-return-type with out-of-class method defn)
This patch caused c++/56639: when within a function we were trying to
parse something that could be either a declaration or an expression, we
went to set current_class_ptr and failed the assertion that it wasn't
already set. We could save and restore the value, but instead with this
patch I take advantage of the fact that there can never be a declaration
with a qualified-id at function scope.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 1d92c03f05ea76a2c10b491f4b31852c8a6b04d5
Author: Jason Merrill
Date: Sun Mar 17 21:48:31 2013 -0400
PR c++/54359
PR c++/56639
* parser.c (cp_parser_direct_declarator): Bail if we see a
qualified-id not at namespace scope.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 0222e90..23fe3f3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16707,9 +16707,18 @@ cp_parser_direct_declarator (cp_parser* parser,
handle_declarator:;
scope = get_scope_of_declarator (declarator);
if (scope)
- /* Any names that appear after the declarator-id for a
- member are looked up in the containing scope. */
- pushed_scope = push_scope (scope);
+ {
+ /* Any names that appear after the declarator-id for a
+ member are looked up in the containing scope. */
+ if (at_function_scope_p ())
+ {
+ /* But declarations with qualified-ids can't appear in a
+ function. */
+ cp_parser_error (parser, "qualified-id in declaration");
+ break;
+ }
+ pushed_scope = push_scope (scope);
+ }
parser->in_declarator_p = true;
if ((ctor_dtor_or_conv_p && *ctor_dtor_or_conv_p)
|| (declarator && declarator->kind == cdk_id))
diff --git a/gcc/testsuite/g++.dg/parse/typename7.C b/gcc/testsuite/g++.dg/parse/typename7.C
index 2d823f8..6ec7696 100644
--- a/gcc/testsuite/g++.dg/parse/typename7.C
+++ b/gcc/testsuite/g++.dg/parse/typename7.C
@@ -22,7 +22,7 @@ struct B
A().bar(t); } // { dg-error "expected|parse error|no matching" }
// { dg-message "candidate" "candidate note" { target *-*-* } 22 }
void bad(T t) {
-B::bar(t); } // { dg-error "invalid|not a template" }
+B::bar(t); } // { dg-error "invalid|qualified-id|not a template" }
};
void baz()
diff --git a/gcc/testsuite/g++.dg/template/arrow2.C b/gcc/testsuite/g++.dg/template/arrow2.C
new file mode 100644
index 000..8ec9e01
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/arrow2.C
@@ -0,0 +1,12 @@
+// PR c++/56639
+
+struct A {
+ int i;
+ static A* f();
+};
+
+struct B {
+ void g() {
+int (A::f()->i);
+ }
+};
