Re: mips SNaN/QNaN is swapped
Hi! On Thu, 20 Jun 2013 15:08:16 -0700, Ian Lance Taylor wrote: > Thomas Schwinge writes: > > On Sun, 05 May 2013 18:55:09 -0700, Ian Lance Taylor wrote: > >> Thomas Schwinge writes: > >> > >> >> libgcc/ > >> >> * fp-bit.c (unpack_d, pack_d): Properly preserve and restore a > >> >> NaN's payload. > >> >> * fp-bit.h [FLOAT] (QUIET_NAN): Correct value. > >> > >> This is OK. > > > > Joseph suggested these two bug-fix commits (trunk r198621 and r198622) > > should be applied to earlier release branches, too. OK? Joseph, which release branches would you like me to commit these two patches to? > The RM's, including Joseph, are in charge of the release branches. You > don't need my separate OK. OK, thanks. Grüße, Thomas pgppyEOJLrXYZ.pgp Description: PGP signature
[RS6000] powerpc64le vec splat
A number of places in the rs6000 backend assume the value for a vec
splat can be found at element nunits-1 of a vector constant, which is
wrong for little-endian. This patch fixes them and the ICE found
when running altivec-consts.c on powerpc64le.
I've also updated the testcase so that it passes for little-endian.
vspltish() and vspltisw() don't do the right thing little-endian, nor
is it easy to make the function work. Consider
v16qi v = { 0, 15, 0, 15, 0, 15, 0, 15, 0, 15, 0, 15, 0, 15, 0, 15 };
vspltish (w, 15);
vs
v8hi v = { 15, 15, 15, 15, 15, 15, 15, 15 };
vspltish (w, 15);
So rather than write two or three variants to build constants the
right way, I just simply use static arrays. I've also added a
scan-assembler-not to make sure none of the vector constants are
loaded from memory, and a new test that has constants appropriate for
little-endian optimisation.
Bootstrapped and regression tested powerpc64-linux. OK for mainline
and 4.8?
gcc/
* config/rs6000/rs6000.c (vspltis_constant): Correct for little-endian.
(gen_easy_altivec_constant): Likewise.
* config/rs6000/predicates.md (easy_vector_constant_add_self,
easy_vector_constant_msb): Likewise.
gcc/testsuite/
* gcc.target/powerpc/altivec-consts.c: Correct for little-endian.
Add scan-assembler-not "lvx".
* gcc.target/powerpc/le-altivec-consts.c: New.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 200274)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -4657,7 +4662,7 @@ vspltis_constant (rtx op, unsigned step, unsigned
bitsize = GET_MODE_BITSIZE (inner);
mask = GET_MODE_MASK (inner);
- val = const_vector_elt_as_int (op, nunits - 1);
+ val = const_vector_elt_as_int (op, BYTES_BIG_ENDIAN ? nunits - 1 : 0);
splat_val = val;
msb_val = val > 0 ? 0 : -1;
@@ -4697,7 +4702,7 @@ vspltis_constant (rtx op, unsigned step, unsigned
for (i = 0; i < nunits - 1; ++i)
{
HOST_WIDE_INT desired_val;
- if (((i + 1) & (step - 1)) == 0)
+ if (((BYTES_BIG_ENDIAN ? i + 1 : i) & (step - 1)) == 0)
desired_val = val;
else
desired_val = msb_val;
@@ -4782,13 +4787,13 @@ gen_easy_altivec_constant (rtx op)
{
enum machine_mode mode = GET_MODE (op);
int nunits = GET_MODE_NUNITS (mode);
- rtx last = CONST_VECTOR_ELT (op, nunits - 1);
+ rtx val = CONST_VECTOR_ELT (op, BYTES_BIG_ENDIAN ? nunits - 1 : 0);
unsigned step = nunits / 4;
unsigned copies = 1;
/* Start with a vspltisw. */
if (vspltis_constant (op, step, copies))
-return gen_rtx_VEC_DUPLICATE (V4SImode, gen_lowpart (SImode, last));
+return gen_rtx_VEC_DUPLICATE (V4SImode, gen_lowpart (SImode, val));
/* Then try with a vspltish. */
if (step == 1)
@@ -4797,7 +4802,7 @@ gen_easy_altivec_constant (rtx op)
step >>= 1;
if (vspltis_constant (op, step, copies))
-return gen_rtx_VEC_DUPLICATE (V8HImode, gen_lowpart (HImode, last));
+return gen_rtx_VEC_DUPLICATE (V8HImode, gen_lowpart (HImode, val));
/* And finally a vspltisb. */
if (step == 1)
@@ -4806,7 +4811,7 @@ gen_easy_altivec_constant (rtx op)
step >>= 1;
if (vspltis_constant (op, step, copies))
-return gen_rtx_VEC_DUPLICATE (V16QImode, gen_lowpart (QImode, last));
+return gen_rtx_VEC_DUPLICATE (V16QImode, gen_lowpart (QImode, val));
gcc_unreachable ();
}
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 200274)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -527,9 +527,11 @@
(match_test "easy_altivec_constant (op, mode)")))
{
HOST_WIDE_INT val;
+ int elt;
if (mode == V2DImode || mode == V2DFmode)
return 0;
- val = const_vector_elt_as_int (op, GET_MODE_NUNITS (mode) - 1);
+ elt = BYTES_BIG_ENDIAN ? GET_MODE_NUNITS (mode) - 1 : 0;
+ val = const_vector_elt_as_int (op, elt);
val = ((val & 0xff) ^ 0x80) - 0x80;
return EASY_VECTOR_15_ADD_SELF (val);
})
@@ -541,9 +543,11 @@
(match_test "easy_altivec_constant (op, mode)")))
{
HOST_WIDE_INT val;
+ int elt;
if (mode == V2DImode || mode == V2DFmode)
return 0;
- val = const_vector_elt_as_int (op, GET_MODE_NUNITS (mode) - 1);
+ elt = BYTES_BIG_ENDIAN ? GET_MODE_NUNITS (mode) - 1 : 0;
+ val = const_vector_elt_as_int (op, elt);
return EASY_VECTOR_MSB (val, GET_MODE_INNER (mode));
})
Index: gcc/testsuite/gcc.target/powerpc/le-altivec-consts.c
===
--- gcc/testsuite/gcc.target/powerpc/le-altivec-consts.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/le-altivec-consts.c(revision 0)
@@ -0,0 +1,253 @@
+/* { dg-do run { target { powerpc*-*-* && vmx_hw } } } */
+/* { dg-do compile { target { powerpc*-*-* && { ! vmx_hw } } } } */
+/* { dg-require-effective-target pow
[c++-concepts] merge from trunk
At revision 200282. Andrew -- there was a slight conflict with the new usage of is_binary_trait. I think I resolved it properly, but double check. -- Gaby
Go patch committed: Really only make descriptors when needed
And this patch fixes the last patch to *really* only make function
descriptors when they are needed. Sigh. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.8
branch.
Ian
diff -r 3081c3c4d620 go/expressions.cc
--- a/go/expressions.cc Thu Jun 20 17:08:43 2013 -0700
+++ b/go/expressions.cc Thu Jun 20 17:16:00 2013 -0700
@@ -1242,24 +1242,6 @@
: Expression::traverse(&this->closure_, traverse));
}
-// Lower a function reference. If this reference is not called
-// directly, make sure there is a function descriptor.
-
-Expression*
-Func_expression::do_lower(Gogo* gogo, Named_object*, Statement_inserter*, int)
-{
- // Make sure that the descriptor exists. FIXME: If the function is
- // only ever called, and is never referenced otherwise, then we
- // don't need the descriptor. We could do that with another pass
- // over the tree.
- if (this->closure_ == NULL
- && this->function_->is_function()
- && !this->function_->func_value()->is_method())
-this->function_->func_value()->descriptor(gogo, this->function_);
-
- return this;
-}
-
// Return the type of a function expression.
Type*
diff -r 3081c3c4d620 go/expressions.h
--- a/go/expressions.h Thu Jun 20 17:08:43 2013 -0700
+++ b/go/expressions.h Thu Jun 20 17:16:00 2013 -0700
@@ -1524,9 +1524,6 @@
int
do_traverse(Traverse*);
- Expression*
- do_lower(Gogo*, Named_object*, Statement_inserter*, int);
-
Type*
do_type();
Re: C++ PATCH for c++/55149 (lambda VLA capture)
On 06/20/2013 08:26 PM, Jason Merrill wrote: Instantiation of a VLA capture in a template wasn't working properly; this fixes it. Along with this, which fixes the type of an instantiation of the MINUS_EXPR. commit c37ab236406b9acf4423e80554055bf72d7be5fa Author: Jason Merrill Date: Thu Jun 20 17:42:16 2013 -0400 * decl.c (compute_array_index_type): Use size_one_node. diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 9eb1d12..dad1e10 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -8241,7 +8241,7 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain) constant. Just build the index type and mark that it requires structural equality checks. */ itype = build_index_type (build_min (MINUS_EXPR, sizetype, - size, integer_one_node)); + size, size_one_node)); TYPE_DEPENDENT_P (itype) = 1; TYPE_DEPENDENT_P_VALID (itype) = 1; SET_TYPE_STRUCTURAL_EQUALITY (itype);
C++ PATCH for c++/55149 (lambda VLA capture)
Instantiation of a VLA capture in a template wasn't working properly;
this fixes it.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9e88ab6e258122ce7d4a709919df56f7c1514c06
Author: Jason Merrill
Date: Thu Jun 13 09:29:11 2013 -0400
PR c++/55149
* decl.c (compute_array_index_type): Don't reject VLAs in SFINAE
context if we're in C++14 mode.
* tree.c (array_of_runtime_bound_p): Return true for a dependent
bound that is not potentually constant.
* cp-tree.h (DECL_VLA_CAPTURE_P, REFERENCE_VLA_OK): New.
* pt.c (tsubst) [REFERENCE_TYPE]: Check REFERENCE_VLA_OK.
* semantics.c (build_lambda_object): Don't rvalue a VLA capture.
(build_capture_proxy): Set REFERENCE_VLA_OK.
(vla_capture_type): Make it a proper C++ class.
(add_capture): Set DECL_VLA_CAPTURE_P. Don't pre-digest the
initializer.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 9fc4aeb..cf54acf 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -126,6 +126,7 @@ c-common.h, not after.
5: CLASS_TYPE_P (in RECORD_TYPE and UNION_TYPE)
ENUM_FIXED_UNDERLYING_TYPE_P (in ENUMERAL_TYPE)
AUTO_IS_DECLTYPE (in TEMPLATE_TYPE_PARM)
+ REFERENCE_VLA_OK (in REFERENCE_TYPE)
6: TYPE_DEPENDENT_P_VALID
Usage of DECL_LANG_FLAG_?:
@@ -139,6 +140,7 @@ c-common.h, not after.
DECL_MEMBER_TEMPLATE_P (in TEMPLATE_DECL)
FUNCTION_PARAMETER_PACK_P (in PARM_DECL)
USING_DECL_TYPENAME_P (in USING_DECL)
+ DECL_VLA_CAPTURE_P (in FIELD_DECL)
2: DECL_THIS_EXTERN (in VAR_DECL or FUNCTION_DECL).
DECL_IMPLICIT_TYPEDEF_P (in a TYPE_DECL)
3: DECL_IN_AGGR_P.
@@ -2979,6 +2981,11 @@ extern void decl_shadowed_for_var_insert (tree, tree);
&& (TREE_CODE (TREE_TYPE (TREE_OPERAND ((NODE), 0))) \
== REFERENCE_TYPE))
+/* True if NODE is a REFERENCE_TYPE which is OK to instantiate to be a
+ reference to VLA type, because it's used for VLA capture. */
+#define REFERENCE_VLA_OK(NODE) \
+ (TYPE_LANG_FLAG_5 (REFERENCE_TYPE_CHECK (NODE)))
+
#define NEW_EXPR_USE_GLOBAL(NODE) \
TREE_LANG_FLAG_0 (NEW_EXPR_CHECK (NODE))
#define DELETE_EXPR_USE_GLOBAL(NODE) \
@@ -3616,6 +3623,11 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
#define DECL_THIS_STATIC(NODE) \
DECL_LANG_FLAG_6 (VAR_FUNCTION_OR_PARM_DECL_CHECK (NODE))
+/* Nonzero for FIELD_DECL node means that this field is a lambda capture
+ field for an array of runtime bound. */
+#define DECL_VLA_CAPTURE_P(NODE) \
+ DECL_LANG_FLAG_1 (FIELD_DECL_CHECK (NODE))
+
/* Nonzero for FIELD_DECL node means that this field is a base class
of the parent object, as opposed to a member field. */
#define DECL_FIELD_IS_BASE(NODE) \
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index dad1e10..225f131 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8296,7 +8296,8 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
else if (TREE_CONSTANT (size)
/* We don't allow VLAs at non-function scopes, or during
tentative template substitution. */
- || !at_function_scope_p () || !(complain & tf_error))
+ || !at_function_scope_p ()
+ || (cxx_dialect < cxx1y && !(complain & tf_error)))
{
if (!(complain & tf_error))
return error_mark_node;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 256f9ab..4a0f411 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11608,7 +11608,9 @@ tsubst (tree t, tree args, tsubst_flags_t complain, tree in_decl)
r = cp_build_reference_type (type, TYPE_REF_IS_RVALUE (t));
r = cp_build_qualified_type_real (r, cp_type_quals (t), complain);
- if (cxx_dialect >= cxx1y && array_of_runtime_bound_p (type))
+ if (cxx_dialect >= cxx1y
+ && !(TREE_CODE (t) == REFERENCE_TYPE && REFERENCE_VLA_OK (t))
+ && array_of_runtime_bound_p (type))
{
if (complain & tf_warning_or_error)
pedwarn
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 0a700b7..135ef74 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9033,6 +9033,7 @@ build_lambda_object (tree lambda_expr)
if (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE)
val = build_array_copy (val);
else if (DECL_NORMAL_CAPTURE_P (field)
+ && !DECL_VLA_CAPTURE_P (field)
&& TREE_CODE (TREE_TYPE (field)) != REFERENCE_TYPE)
{
/* "the entities that are captured by copy are used to
@@ -9404,8 +9405,7 @@ build_capture_proxy (tree member)
type = lambda_proxy_type (object);
- if (TREE_CODE (type) == RECORD_TYPE
- && TYPE_NAME (type) == NULL_TREE)
+ if (DECL_VLA_CAPTURE_P (member))
{
/* Rebuild the VLA type from the pointer and maxindex. */
tree field = next_initializable_field (TYPE_FIELDS (type));
@@ -9414,8 +9414,9 @@ build_capture_proxy (tree member)
tree max = build_simple_component_ref (object, field);
type = build_array_type (TREE_TYPE (TREE_TYPE (ptr)),
build_index_type (max));
- object = convert (build_reference_type (type), p
Go patch committed: Only make function descriptors if needed
This is a follow up to the last big patch, adding function descriptors
to the Go frontend. This patch adds another compilation pass to only
create the function descriptors if they are needed: if the function is
exported, or if it is referenced in some way other than calling it.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r a4bae46290c3 go/expressions.cc
--- a/go/expressions.cc Thu Jun 20 13:21:55 2013 -0700
+++ b/go/expressions.cc Thu Jun 20 17:04:56 2013 -0700
@@ -1385,62 +1385,24 @@
return new Func_expression(function, closure, location);
}
-// A function descriptor. A function descriptor is a struct with a
-// single field pointing to the function code. This is used for
-// functions without closures.
-
-class Func_descriptor_expression : public Expression
-{
- public:
- Func_descriptor_expression(Named_object* fn, Named_object* dfn)
-: Expression(EXPRESSION_FUNC_DESCRIPTOR, fn->location()),
- fn_(fn), dfn_(dfn), dvar_(NULL)
- {
-go_assert(!fn->is_function() || !fn->func_value()->needs_closure());
- }
-
- // Make the function descriptor type, so that it can be converted.
- static void
- make_func_descriptor_type();
-
- protected:
- int
- do_traverse(Traverse*)
- { return TRAVERSE_CONTINUE; }
-
- Type*
- do_type();
-
- void
- do_determine_type(const Type_context*)
- { }
-
- Expression*
- do_copy()
- { return Expression::make_func_descriptor(this->fn_, this->dfn_); }
-
- bool
- do_is_addressable() const
- { return true; }
-
- tree
- do_get_tree(Translate_context*);
-
- void
- do_dump_expression(Ast_dump_context* context) const
- { context->ostream() << "[descriptor " << this->fn_->name() << "]"; }
-
- private:
- // The type of all function descriptors.
- static Type* descriptor_type;
-
- // The function for which this is the descriptor.
- Named_object* fn_;
- // The descriptor function.
- Named_object* dfn_;
- // The descriptor variable.
- Bvariable* dvar_;
-};
+// Class Func_descriptor_expression.
+
+// Constructor.
+
+Func_descriptor_expression::Func_descriptor_expression(Named_object* fn)
+ : Expression(EXPRESSION_FUNC_DESCRIPTOR, fn->location()),
+fn_(fn), dfn_(NULL), dvar_(NULL)
+{
+ go_assert(!fn->is_function() || !fn->func_value()->needs_closure());
+}
+
+// Traversal.
+
+int
+Func_descriptor_expression::do_traverse(Traverse*)
+{
+ return TRAVERSE_CONTINUE;
+}
// All function descriptors have the same type.
@@ -1464,6 +1426,18 @@
return Func_descriptor_expression::descriptor_type;
}
+// Copy a Func_descriptor_expression;
+
+Expression*
+Func_descriptor_expression::do_copy()
+{
+ Func_descriptor_expression* fde =
+Expression::make_func_descriptor(this->fn_);
+ if (this->dfn_ != NULL)
+fde->set_descriptor_wrapper(this->dfn_);
+ return fde;
+}
+
// The tree for a function descriptor.
tree
@@ -1519,12 +1493,20 @@
return var_to_tree(bvar);
}
+// Print a function descriptor expression.
+
+void
+Func_descriptor_expression::do_dump_expression(Ast_dump_context* context) const
+{
+ context->ostream() << "[descriptor " << this->fn_->name() << "]";
+}
+
// Make a function descriptor expression.
-Expression*
-Expression::make_func_descriptor(Named_object* fn, Named_object* dfn)
-{
- return new Func_descriptor_expression(fn, dfn);
+Func_descriptor_expression*
+Expression::make_func_descriptor(Named_object* fn)
+{
+ return new Func_descriptor_expression(fn);
}
// Make the function descriptor type, so that it can be converted.
diff -r a4bae46290c3 go/expressions.h
--- a/go/expressions.h Thu Jun 20 13:21:55 2013 -0700
+++ b/go/expressions.h Thu Jun 20 17:04:56 2013 -0700
@@ -32,6 +32,7 @@
class Binary_expression;
class Call_expression;
class Func_expression;
+class Func_descriptor_expression;
class Unknown_expression;
class Index_expression;
class Map_index_expression;
@@ -161,10 +162,9 @@
// Make a function descriptor, an immutable struct with a single
// field that points to the function code. This may only be used
// with functions that do not have closures. FN is the function for
- // which we are making the descriptor. DFN is the descriptor
- // function wrapper.
- static Expression*
- make_func_descriptor(Named_object* fn, Named_object* dfn);
+ // which we are making the descriptor.
+ static Func_descriptor_expression*
+ make_func_descriptor(Named_object* fn);
// Make a reference to the code of a function. This is used to set
// descriptor and closure fields.
@@ -1562,6 +1562,63 @@
Expression* closure_;
};
+// A function descriptor. A function descriptor is a struct with a
+// single field pointing to the function code. This is used for
+// functions without closures.
+
+class Func_descriptor_expression : public Expression
+{
+ public:
+ Func_descriptor_expression(Named_object* fn);
+
+ // Set the descriptor wrapper.
+ void
+ set_descriptor_wrapper(Named_object* dfn)
+ {
+go_assert(this->dfn_ == NULL);
+
Re: mips SNaN/QNaN is swapped
Thomas Schwinge writes: > Hi! > > On Sun, 05 May 2013 18:55:09 -0700, Ian Lance Taylor wrote: >> Thomas Schwinge writes: >> >> >> libgcc/ >> >> * fp-bit.c (unpack_d, pack_d): Properly preserve and restore a >> >> NaN's payload. >> >> * fp-bit.h [FLOAT] (QUIET_NAN): Correct value. >> >> This is OK. > > Joseph suggested these two bug-fix commits (trunk r198621 and r198622) > should be applied to earlier release branches, too. OK? The RM's, including Joseph, are in charge of the release branches. You don't need my separate OK. Ian
Re: mips SNaN/QNaN is swapped
Hi! On Sun, 05 May 2013 18:55:09 -0700, Ian Lance Taylor wrote: > Thomas Schwinge writes: > > >> libgcc/ > >>* fp-bit.c (unpack_d, pack_d): Properly preserve and restore a > >>NaN's payload. > >>* fp-bit.h [FLOAT] (QUIET_NAN): Correct value. > > This is OK. Joseph suggested these two bug-fix commits (trunk r198621 and r198622) should be applied to earlier release branches, too. OK? Grüße, Thomas pgpFd3zW4t43_.pgp Description: PGP signature
[linaro/gcc-4_8-branch] Backport from trunk
Hi, I have just backported r198683 from trunk to linaro/gcc-4_8-branch (as rev 200267). (It's the support of Address Sanitizer for ARM) Thanks, Christophe.
Re: [patch] set MULTIARCH_DIRNAME for multilib architectures
On Thu, Jun 20, 2013 at 02:26:12PM +0200, Matthias Klose wrote: > Am 13.06.2013 11:42, schrieb Richard Sandiford: > > "Bernhard Reutner-Fischer" writes: > >> On 12 June 2013 20:20:50 Richard Sandiford > >> wrote: > >>> Matthias Klose writes: > Index: config/mips/t-linux64 > === > --- config/mips/t-linux64(revision 200012) > +++ config/mips/t-linux64(working copy) > @@ -24,3 +24,13 @@ > ../lib32$(call > >>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ > ../lib$(call > if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ > ../lib64$(call > if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > + > +ifneq (,$(findstring abin32,$(target))) > +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) > +else > +ifneq (,$(findstring abi64,$(target))) > +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) > +else > +MULTIARCH_DIRNAME = $(call > >>> if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) > +endif > +endif > >>> > >>> findstring seems a bit fragile for a full triple. I think it would > >>> be better to have something similar to the current MIPS_SOFT definition: > >>> > >>> MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, > >>> $(target_cpu_default)) $(filter soft, $(with_float))),soft) > >>> > >>> but for ABIs. It could then also take with_abi into account. > >>> Maybe something like: > >>> > >>> MIPS_ABI = $(or $(with_abi), \ > >>> $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > >>> $(target_cpu_default)), n32), \ > >>> o32) > >>> > >>> (completely untested). > >> > >> Bikeshedding: > >> Doko would know, but ISTR that $(or) did not exist in make-3.80 which is > >> currently the minimum prerequisite, fwiw. > > > > Gah, that's a pity. Thanks for the catch though. Maybe firstword > > would be OK instead. > > > > I see I also fell into the usual ABI trap. It wouldn't have affected > > the use in this patch, but the default ought to be "32" rather than "o32". > > the define is in tm_defines, not target_cpu_default. > > MIPS_ABI = $(or $(with_abi), \ > $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ > $(tm_defines)), n32), \ > 32) > > However I can't see yet how this should be used. Maybe Aurelian could come up > with a tested version of this patch? > I don't have a lot of time right now, will look at that in details next week. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Fix typo in `aot-compile' option list
On 06/20/2013 09:09 PM, Roland Lutz wrote: > Signed-off-by: Roland Lutz > --- > libjava/contrib/aot-compile.in |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libjava/contrib/aot-compile.in b/libjava/contrib/aot-compile.in > index 91cfc67..2ee6739 100644 > --- a/libjava/contrib/aot-compile.in > +++ b/libjava/contrib/aot-compile.in > @@ -52,7 +52,7 @@ try: > sys.argv[1:], > "M:C:D:m:c:l:e:", > ["make=", "gcj=", "dbtool=", > - "makeflags=" "gcjflags=", "ldflags=", > + "makeflags=", "gcjflags=", "ldflags=", >"exclude="]) > srcdir, dstdir = args > except: > OK with a ChangeLog entry. Andrew.
[PATCH] Fix typo in `aot-compile' option list
Signed-off-by: Roland Lutz --- libjava/contrib/aot-compile.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libjava/contrib/aot-compile.in b/libjava/contrib/aot-compile.in index 91cfc67..2ee6739 100644 --- a/libjava/contrib/aot-compile.in +++ b/libjava/contrib/aot-compile.in @@ -52,7 +52,7 @@ try: sys.argv[1:], "M:C:D:m:c:l:e:", ["make=", "gcj=", "dbtool=", - "makeflags=" "gcjflags=", "ldflags=", + "makeflags=", "gcjflags=", "ldflags=", "exclude="]) srcdir, dstdir = args except: -- 1.7.10.4
PATCH to add include from system.h
Since we poison "malloc" and friends in system.h, any C++ code that includes a standard library header such as , which in turn includes , will get poisoning errors due to lines like #undef malloc using ::malloc; The solution is to include before poisoning those identifiers. Oleg posted a variant of this patch last year, which included instead of ; my patch includes both to avoid issues with other library implementations in which might not declare functions in the global namespace. Tested x86_64-pc-linux-gnu, applying to trunk. commit 33be921c304a8bf38bbf5ae30b3489a01be4763c Author: Jason Merrill Date: Mon Jun 10 21:17:00 2013 -0400 * system.h: Include as well as . diff --git a/gcc/system.h b/gcc/system.h index 41cd565..f10ba4a 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -226,6 +226,14 @@ extern int errno; # include #endif +/* When compiling C++ we need to include as well as so + that it is processed before we poison "malloc"; otherwise, if a source + file uses a standard library header that includes , we will get + an error about 'using std::malloc'. */ +#ifdef __cplusplus +#include +#endif + /* Undef vec_free from AIX stdlib.h header which conflicts with vec.h. */ #undef vec_free
Re: patch to fix PR57604
Thanks Vlad.
Vladimir Makarov writes:
> Index: lra.c
> ===
> --- lra.c (revision 200174)
> +++ lra.c (working copy)
> @@ -242,6 +242,42 @@ lra_delete_dead_insn (rtx insn)
>lra_set_insn_deleted (insn);
> }
>
> +/* Emit insn x = y + z. Return NULL if we failed to do it.
> + Otherwise, return the insn. We don't use gen_add3_insn as it might
> + clobber CC. */
> +static rtx
> +emit_add3_insn (rtx x, rtx y, rtx z)
> +{
> + rtx insn, last;
> +
> + last = get_last_insn ();
> + insn = emit_insn (gen_rtx_SET (VOIDmode, x,
> + gen_rtx_PLUS (GET_MODE (y), y, z)));
> + if (recog_memoized (insn) < 0)
> +{
> + delete_insns_since (last);
> + insn = NULL_RTX;
> +}
> + return insn;
> +}
> +
> +/* Emit insn x = x + y. Return the insn. We use gen_add2_insn as the
> + last resort. */
> +static rtx
> +emit_add2_insn (rtx x, rtx y)
> +{
> + rtx insn;
> +
> + insn = emit_add3_insn (x, x, y);
> + if (insn == NULL_RTX)
> +{
> + insn = gen_add2_insn (x, y);
> + if (insn != NULL_RTX)
> + emit_insn (insn);
> +}
> + return insn;
> +}
Why is gen_add2_insn allowed and gen_add3_insn not? They both use
the same add3 optab, so one seems just as likely as the other
to clobber the flags.
Maybe it would help to have an addptr3 optab that can only be used
for values that are known to be pointers and that is specifically not
allowed to clobber the flags. Or an "lea2" optab that is required
to accept all "m" addresses.
> @@ -306,12 +342,14 @@ lra_emit_add (rtx x, rtx y, rtx z)
> || (disp != NULL_RTX && ! CONSTANT_P (disp))
> || (scale != NULL_RTX && ! CONSTANT_P (scale)))
> {
> - /* It is not an address generation. Probably we have no 3 op
> - add. Last chance is to use 2-op add insn. */
> + /* Probably we have no 3 op add. Last chance is to use 2-op
> + add insn. To succeed, don't move Z to X as an address
> + segment always comes in Y. Otherwise, we might fail when
> + adding the address segment to register. */
Do you mean "segment" in the x86 sense, or something else? I still don't
really understand.
Thanks,
Richard
C++ PATCH to build a TEMPLATE_DECL for a partial specialization
It has always seemed odd that we didn't build a TEMPLATE_DECL for a
partial specialization, and with the ongoing concepts work it has become
more important to have one so that we can attach any requirements to it.
Note that there is still no way to get from the type of a partial
specialization to its template other than by way of the primary
template's list of partial specializations.
The second patch adds some missing _CHECK uses.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5961bf601b6e2cf859d0cedf9b6a730e2160d8f4
Author: Jason Merrill
Date: Wed Jun 19 14:39:17 2013 -0400
* pt.c (process_partial_specialization): Build a TEMPLATE_DECL for
a partial specialization.
(tsubst_decl): Don't clobber CLASSTYPE_TI_TEMPLATE of a partial
specialization.
(most_specialized_class): Adjust.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7896386..cf54acf 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3739,11 +3739,10 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
specializations of this template. (Full specializations are not
recorded on this list.) The TREE_PURPOSE holds the arguments used
in the partial specialization (e.g., for `template struct
- S' this will be `T*'.) The arguments will also include
- any outer template arguments. The TREE_VALUE holds the innermost
- template parameters for the specialization (e.g., `T' in the
- example above.) The TREE_TYPE is the _TYPE node for the partial
- specialization.
+ S' this will be `T*, int'.) The arguments will also include
+ any outer template arguments. The TREE_VALUE holds the TEMPLATE_DECL
+ for the partial specialization. The TREE_TYPE is the _TYPE node for
+ the partial specialization.
This list is not used for other templates. */
#define DECL_TEMPLATE_SPECIALIZATIONS(NODE) \
@@ -3813,9 +3812,10 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
#define SET_DECL_SELF_REFERENCE_P(NODE) \
(DECL_LANG_FLAG_4 (NODE) = 1)
-/* A `primary' template is one that has its own template header. A
- member function of a class template is a template, but not primary.
- A member template is primary. Friend templates are primary, too. */
+/* A `primary' template is one that has its own template header and is not
+ a partial specialization. A member function of a class template is a
+ template, but not primary. A member template is primary. Friend
+ templates are primary, too. */
/* Returns the primary template corresponding to these parameters. */
#define DECL_PRIMARY_TEMPLATE(NODE) \
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5e3cf07..4a0f411 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -4246,8 +4246,16 @@ process_partial_specialization (tree decl)
/* We should only get here once. */
gcc_assert (!COMPLETE_TYPE_P (type));
+ tree tmpl = build_template_decl (decl, current_template_parms,
+ DECL_MEMBER_TEMPLATE_P (maintmpl));
+ TREE_TYPE (tmpl) = type;
+ DECL_TEMPLATE_RESULT (tmpl) = decl;
+ SET_DECL_TEMPLATE_SPECIALIZATION (tmpl);
+ DECL_TEMPLATE_INFO (tmpl) = build_template_info (maintmpl, specargs);
+ DECL_PRIMARY_TEMPLATE (tmpl) = maintmpl;
+
DECL_TEMPLATE_SPECIALIZATIONS (maintmpl)
-= tree_cons (specargs, inner_parms,
+= tree_cons (specargs, tmpl,
DECL_TEMPLATE_SPECIALIZATIONS (maintmpl));
TREE_TYPE (DECL_TEMPLATE_SPECIALIZATIONS (maintmpl)) = type;
@@ -10091,7 +10099,10 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
RETURN (error_mark_node);
TREE_TYPE (r) = new_type;
- CLASSTYPE_TI_TEMPLATE (new_type) = r;
+ /* For a partial specialization, we need to keep pointing to
+ the primary template. */
+ if (!DECL_TEMPLATE_SPECIALIZATION (t))
+ CLASSTYPE_TI_TEMPLATE (new_type) = r;
DECL_TEMPLATE_RESULT (r) = TYPE_MAIN_DECL (new_type);
DECL_TI_ARGS (r) = CLASSTYPE_TI_ARGS (new_type);
DECL_CONTEXT (r) = TYPE_CONTEXT (new_type);
@@ -18115,7 +18126,8 @@ most_specialized_class (tree type, tree tmpl, tsubst_flags_t complain)
{
tree partial_spec_args;
tree spec_args;
- tree parms = TREE_VALUE (t);
+ tree spec_tmpl = TREE_VALUE (t);
+ tree orig_parms = DECL_INNERMOST_TEMPLATE_PARMS (spec_tmpl);
partial_spec_args = CLASSTYPE_TI_ARGS (TREE_TYPE (t));
@@ -18123,24 +18135,14 @@ most_specialized_class (tree type, tree tmpl, tsubst_flags_t complain)
if (outer_args)
{
- int i;
-
/* Discard the outer levels of args, and then substitute in the
template args from the enclosing class. */
partial_spec_args = INNERMOST_TEMPLATE_ARGS (partial_spec_args);
partial_spec_args = tsubst_template_args
(partial_spec_args, outer_args, tf_none, NULL_TREE);
- /* PARMS already refers to just the innermost parms, but the
- template parms in partial_spec_args had their levels lowered
- by tsubst, so we need to
Re: [c++-concepts] code review
On 06/20/2013 01:23 PM, Jason Merrill wrote: Since Gaby prefers SVN, let's keep using the SVN branch; it really isn't much less convenient than a git-only branch. The main difference is 'git svn rebase'/'git svn dcommit' instead of 'git pull'/'git push'. The one caveat is that git-svn historically hasn't handled merges very well. I think git-svn v1.8.3 or newer can do the right thing, but I haven't tested it, so it's probably best to keep doing merges with the svn client for the time being. Jason
Re: [PATCH 1/2] Improve __atomic_clear/test_and_set documentation
On 06/20/2013 11:14 AM, Andi Kleen wrote:
>>> +It should be only used for operands of type bool or atomic_flag. For
>>> +other types only part of the value may be set.
>>
>> @code{bool}. We have no definition for atomic_flag. Perhaps just
>> @code{char}
>> for now?
>>
>>> +It should be only used for operands of type bool or atomic_flag and
>>
>> Same.
>>
>>> +in conjunction with __atomic_test_and_set.
>>
>> @code{__atomic_test_and_set}.
>
> Ok with these changes?
Yeah.
r~
[PATCH] Set $ac_aux_dir before use in libdecnumber/configure
Set $ac_aux_dir before use in libdecnumber/configure.
libdecnumber/configure uses $ac_aux_dir before it is set, causing incorrect
MISSING value. Fix with explicit AC_CONFIG_AUX_DIR.
Bootstrapped for c/c++. Okay for trunk?
libdecnumber/ChangeLog
2013-06-20 Simon Baldwin
* configure.ac: Add AC_CONFIG_AUX_DIR.
* configure: Regenerated.
Index: libdecnumber/configure.ac
===
--- libdecnumber/configure.ac (revision 200246)
+++ libdecnumber/configure.ac (working copy)
@@ -23,6 +23,7 @@ AC_PREREQ(2.64)
AC_INIT(libdecnumber, [ ], gcc-b...@gcc.gnu.org, libdecnumber)
AC_CONFIG_SRCDIR(decNumber.h)
AC_CONFIG_MACRO_DIR(../config)
+AC_CONFIG_AUX_DIR(..)
# Checks for programs.
AC_PROG_MAKE_SET
Index: libdecnumber/configure
===
--- libdecnumber/configure (revision 200246)
+++ libdecnumber/configure (working copy)
@@ -2220,6 +2220,29 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
+ac_aux_dir=
+for ac_dir in .. "$srcdir"/..; do
+ for ac_t in install-sh install.sh shtool; do
+if test -f "$ac_dir/$ac_t"; then
+ ac_aux_dir=$ac_dir
+ ac_install_sh="$ac_aux_dir/$ac_t -c"
+ break 2
+fi
+ done
+done
+if test -z "$ac_aux_dir"; then
+ as_fn_error "cannot find install-sh, install.sh, or shtool in ..
\"$srcdir\"/.." "$LINENO" 5
+fi
+
+# These three variables are undocumented and unsupported,
+# and are intended to be withdrawn in a future Autoconf release.
+# They can cause serious problems if a builder's source tree is in a directory
+# whose full name contains unusual characters.
+ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
+ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
+ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
+
+
# Checks for programs.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${MAKE-make} sets
\$(MAKE)" >&5
@@ -4458,29 +4481,6 @@ else
fi
-ac_aux_dir=
-for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
- for ac_t in install-sh install.sh shtool; do
-if test -f "$ac_dir/$ac_t"; then
- ac_aux_dir=$ac_dir
- ac_install_sh="$ac_aux_dir/$ac_t -c"
- break 2
-fi
- done
-done
-if test -z "$ac_aux_dir"; then
- as_fn_error "cannot find install-sh, install.sh, or shtool in \"$srcdir\"
\"$srcdir/..\" \"$srcdir/../..\"" "$LINENO" 5
-fi
-
-# These three variables are undocumented and unsupported,
-# and are intended to be withdrawn in a future Autoconf release.
-# They can cause serious problems if a builder's source tree is in a directory
-# whose full name contains unusual characters.
-ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
-ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
-ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
-
-
# Make sure we can run config.sub.
$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
as_fn_error "cannot run $SHELL $ac_aux_dir/config.sub" "$LINENO" 5
Re: [PATCH 1/2] Improve __atomic_clear/test_and_set documentation
> > +It should be only used for operands of type bool or atomic_flag. For
> > +other types only part of the value may be set.
>
> @code{bool}. We have no definition for atomic_flag. Perhaps just @code{char}
> for now?
>
> > +It should be only used for operands of type bool or atomic_flag and
>
> Same.
>
> > +in conjunction with __atomic_test_and_set.
>
> @code{__atomic_test_and_set}.
Ok with these changes?
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
[PATCH, i386]: Fix PR57655, ICE: in create_pre_exit, at mode-switching.c:418
Hello!
x86_64 ABI mandates long double returns in x87 register, so it is
invalid to use --mno-fp-ret-in-387. It just happened that vzeroupper
insertion mode-switching pass tripped on invalid register usage.
2013-06-20 Uros Bizjak
PR target/57655
* config/i386/i386.c (construct_container): Report error if
long double is used with disabled x87 float returns.
testsuite/ChangeLog:
2013-06-20 Uros Bizjak
PR target/57655
* gcc.target/i386/pr57655.c: New test.
Patch was tested on x86_64-pc-linux-gnu {,-m32} and was committed to
mainline SVN. The patch will be backported to all release branches.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 200247)
+++ config/i386/i386.c (working copy)
@@ -6498,7 +6498,7 @@ construct_container (enum machine_mode mode, enum
/* Likewise, error if the ABI requires us to return values in the
x87 registers and the user specified -mno-80387. */
- if (!TARGET_80387 && in_return)
+ if (!TARGET_FLOAT_RETURNS_IN_80387 && in_return)
for (i = 0; i < n; i++)
if (regclass[i] == X86_64_X87_CLASS
|| regclass[i] == X86_64_X87UP_CLASS
Index: testsuite/gcc.target/i386/pr57655.c
===
--- testsuite/gcc.target/i386/pr57655.c (revision 0)
+++ testsuite/gcc.target/i386/pr57655.c (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx -mvzeroupper -mno-fp-ret-in-387" }
+
+/* { dg-error "x87 register return with x87 disabled" "" { target { ! ia32 } }
8 } */
+
+long double
+foo (long double x)
+{
+ return __builtin_ilogbl (x);
+}
Re: [PATCH 2/2] Fix HLE example in manual
On 06/20/2013 06:20 AM, Andi Kleen wrote: > gcc/: > 2013-06-13 Andi Kleen > > * doc/extend.texi: Dont use __atomic_clear in HLE > example. Fix typo. Ok. r~
Re: [PATCH 1/2] Improve __atomic_clear/test_and_set documentation
On 06/20/2013 06:20 AM, Andi Kleen wrote:
> From: Andi Kleen
>
> Document that __atomic_clear and __atomic_test_and_set should
> only be used with bool.
>
> gcc/:
> 2013-06-13 Andi Kleen
>
> * doc/extend.texi: Document that __atomic_clear and
> __atomic_test_and_set should only be used with bool.
> ---
> gcc/doc/extend.texi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 1e1f8b3..aa3abef 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -7438,6 +7438,8 @@ This built-in function performs an atomic test-and-set
> operation on
> the byte at @code{*@var{ptr}}. The byte is set to some implementation
> defined nonzero ``set'' value and the return value is @code{true} if and only
> if the previous contents were ``set''.
> +It should be only used for operands of type bool or atomic_flag. For
> +other types only part of the value may be set.
@code{bool}. We have no definition for atomic_flag. Perhaps just @code{char}
for now?
> +It should be only used for operands of type bool or atomic_flag and
Same.
> +in conjunction with __atomic_test_and_set.
@code{__atomic_test_and_set}.
r~
Re: [PATCH] Cilk Plus Array Notation for C++
> +/* Returns true if there is a length mismatch among exprssions that are at
> the
> + same dimension and one the same side of the equal sign. The Array
> notation
> + lengths (LIST) is passed in as a 2D vector of trees. */
> +
> +static bool
> +cp_length_mismatch_in_expr_p (location_t loc, vec >list)
Other than working on a vec<>, how does this differ from the
length_mismatch_in_expr_p (location_t loc, tree **list, size_t x, size_t y)
in c-family?
> +static inline void
> +clear_all_an_vectors (vec > *value, vec > *start,
> + vec > *length, vec > *stride,
> + vec > *is_vector, vec > *count_down,
> + vec *incr, vec *cmp, vec *ind_init,
> + vec *var)
> +{
> + value->release ();
> + start->release ();
> + length->release ();
> + stride->release ();
> + is_vector->release ();
> + count_down->release ();
> + incr->release ();
> + cmp->release ();
> + ind_init->release ();
> + var->release ();
> +}
10 arrays kept in sync? It's at this point that we should realize that there's
a mistake in how we're arranging the data. This should be one array, with the
element being a structure.
That should significantly improve quite a lot of the functions in this file.
> + init = ARITHMETIC_TYPE_P (new_var_type) ? build_zero_cst (new_var_type)
> + : integer_zero_node;
Why the test for ARITHMETIC_TYPE_P? Surely we always want something of
new_var_type.
> + if (an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_ADD
> + || an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_MUL)
> +new_expr = build_x_modify_expr (location, *new_var, code, func_parm,
> + tf_warning_or_error);
> + if (an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_ZERO
> + || an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_NONZERO
> + || an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_ZERO
> + || an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_NONZERO)
Why not another switch statement here?
r~
Re: [google gcc-4_8] Change size accounting during inlining in lipo mode
Looks good. thanks, David On Thu, Jun 20, 2013 at 10:38 AM, Easwaran Raman wrote: > In lipo mode, this patch updates the overall unit size only when the > eventual function to which the callee is inlined is in primary module. > This is to avoid the situation where the module growth budget is used > up by inlines into auxiliary module functions that never get inlined > into some primary module function. Ok for google/gcc-4_8 branch? > > Thanks, > Easwaran
[google gcc-4_8] Change size accounting during inlining in lipo mode
In lipo mode, this patch updates the overall unit size only when the eventual function to which the callee is inlined is in primary module. This is to avoid the situation where the module growth budget is used up by inlines into auxiliary module functions that never get inlined into some primary module function. Ok for google/gcc-4_8 branch? Thanks, Easwaran lipo_inline.patch Description: Binary data
Re: [c++-concepts] code review
On 06/20/2013 11:50 AM, Andrew Sutton wrote: The c++-concepts SVN branch won't come in with a clone; you need to add it to the fetch list with git config --add remote.origin.fetch refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts Then you can check out a local branch based on it. Already did that. I probably need to do this, right? git checkout -b c++-concepts origin/c++-concepts Right. I just setup using a git-only branch, so the latter. I set up to push changes to asutton/c++-concepts, so submitted should be visible there. Since Gaby prefers SVN, let's keep using the SVN branch; it really isn't much less convenient than a git-only branch. The main difference is 'git svn rebase'/'git svn dcommit' instead of 'git pull'/'git push'. Out of curiosity, how will reviews work? Just walk through the most recently pushed changes on my branch? That's what I was thinking, yes. I should be able to produce diffs to send to Gaby also. I should also be able to use those to patch an SVN checkout and commit from a different repo. git-svn is much more convenient :) Jason
[PATCH] Fix PR tree-optimization/57660
This test is failing on targets with low branch costs. For those
targets we expand the code radically differently and the test really
doesn't make much sense -- much like vrp87.c.
This patch copies the list of targets where the test is meaningless from
vrp87.c.
Installed onto the trunk.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5adbc01..f2d9895 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,9 @@
2013-06-20 Jeff Law
+ PR tree-optimization/57660
+ * gcc.dg/tree-ssa/forwprop-28.c: Don't run test on various targets
+ based on their branch cost.
+
* gcc.dg/tree-ssa/forwprop-28.c: Add missing dg-final.
2013-06-20 Tobias Burnus
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
index 8e870b9..a64987b 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
powerpc*-*-* xtensa*-*-*"} } } */
/* { dg-options "-O2 -fdump-tree-forwprop1" } */
extern char *frob (void);
Re: [patch] libitm: Fix handling of reentrancy in the HTM fastpath
On 20/06/13 05:13, Peter Bergner wrote: > On Thu, 2013-06-20 at 00:51 +0200, Torvald Riegel wrote: >> On Wed, 2013-06-19 at 14:43 -0500, Peter Bergner wrote: > I'd still like to hear from Andreas, whether the reentrant.c test case > with both patches, now works on S390. The patches fix the testcase also on s390. Thanks! Bye, -Andreas-
Re: [PATCH, x86] Use vector moves in memmove expanding
It seems that one of the tests needed a small fix. Attached is a corrected version. On 20 June 2013 17:16, Michael Zolotukhin wrote: > Hi, > I added two tests to verify we generate vector instructions when > vector_loop is used. > Is the patch ok with that change? > > Thanks, Michael > > On 5 June 2013 18:10, Michael Zolotukhin > wrote: >> I'll prepare some tests shortly, >> What about the rest questions? >> >> Thanks, Michael >> >> On 15 May 2013 19:45, H.J. Lu wrote: >>> On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin >>> wrote: Hi HJ, > You use Pmode as the largest integer mode. Is word_mode better > than Pmode since word_mode is DI and Pmode may be SI for x32. I updated the patch to use word_mode instead of Pmode. Bootstrap, make check and Specs2000 are ok. Thanks, Michael On 14 May 2013 19:55, H.J. Lu wrote: > On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin > wrote: >> Hi, >> I attached an updated version of the patch. Looks like the 64-bit issue >> is >> resolved in it (now a vector mode is explicitly chosen instead of TI- or >> another integer mode). Also, some of remarks are fixed in it - some >> others are still not changed, because I don't know what to do with them >> right >> now (see my questions in the previous letter). >> >> Could you take a look at the patch? >> >> I checked it on i386/x86_64 bootstrap and make check, and on >> Specs2000/2006 >> (I checked only stability). >> > > You use Pmode as the largest integer mode. Is word_mode better > than Pmode since word_mode is DI and Pmode may be SI for x32. > > >>> >>> You should include tests to verify that it works as >>> expected. >>> >>> >>> -- >>> H.J. >> >> >> >> -- >> --- >> Best regards, >> Michael V. Zolotukhin, >> Software Engineer >> Intel Corporation. > > > > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation. memmov-5.patch Description: Binary data
Re: [PATCH] libgomp testsuite fixes
On May 30, 2013, at 12:59 PM, Cesar Philippidis wrote: > Here is a patch from our backlog at Mentor Graphics that addresses a > libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following > error with dejagnu > Is it OK for trunk? Ok. Committed revision 200253. > 2013-05-30 Iain Sandoe > Cesar Philippidis > > libgomp/ > * testsuite/lib/libgomp.exp: Reorder lib loads into dependency order. > Do not load_gcc_lib gcc-dg.exp and add a comment as to why. > * testsuite/libgomp.c/c.exp: load_gcc_lib gcc-dg.exp. > * testsuite/libgomp.fortran/fortran.exp: Likewise. > * testsuite/libgomp.graphite/graphite.exp: Likewise. > * testsuite/libgomp.c++/c++.exp: load_gcc_lib gcc-dg.exp. > Use dg-runtest rather than gfortran-dg-runtest.
Re: [PATCH] libitm testsuite fixes
On May 30, 2013, at 1:02 PM, Cesar Philippidis wrote: > Here is a patch from our backlog that addresses a libitm issue where > setting ENABLE_LTO=1 > Is this OK for trunk? Ok. Committed revision 200252. > Cesar Philippidis > > > 2013-05-30 Iain Sandoe > Cesar Philippidis > > libitm/ > * testsuite/lib/libitm.exp: Reorder lib loads into dependency order. > Do not load_gcc_lib gcc-dg.exp and add a comment as to why. > * testsuite/libitm.c/c.exp: load_gcc_lib gcc-dg.exp. > * testsuite/libitm.c++/c++.exp: load_gcc_lib gcc-dg.exp.
Re: [patch] libitm: Fix handling of reentrancy in the HTM fastpath
On 06/20/2013 02:49 AM, Torvald Riegel wrote: > commit c8352d4d9fa5cfa3453a61c581956835de9753e5 > Author: Torvald Riegel > Date: Thu Jun 20 00:46:59 2013 +0200 > > libitm: Handle HTM fastpath in status query functions. Ok. r~
Re: [patch] libitm: Fix handling of reentrancy in the HTM fastpath
On 06/19/2013 07:57 AM, Torvald Riegel wrote: > commit 185af84e365e1bae31aea5afd6e67e81f3c32c72 > Author: Torvald Riegel > Date: Wed Jun 19 16:42:24 2013 +0200 > > libitm: Fix handling of reentrancy in the HTM fastpath. > > PR libitm/57643 Ok. r~
[PATCH] Add missing dg-final to new test
The newly added forwprop-28.c test was missing a dg-final clause to
remove the debugging dump is scans. This trivial patch adds the missing
dg-final.
Installed as obvious.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 6dca973..5adbc01 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2013-06-20 Jeff Law
+
+ * gcc.dg/tree-ssa/forwprop-28.c: Add missing dg-final.
+
2013-06-20 Tobias Burnus
PR fortran/57633
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
index 09d96ad..8e870b9 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
@@ -74,3 +74,5 @@ test_8 (int code)
}
/* { dg-final { scan-tree-dump-times "Replaced" 8 "forwprop1"} } */
+/* { dg-final { cleanup-tree-dump "forwprop1" } } */
+
Re: [c++-concepts] code review
> The c++-concepts SVN branch won't come in with a clone; you need to add it > to the fetch list with > > git config --add remote.origin.fetch > refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts > > Then you can check out a local branch based on it. Already did that. I probably need to do this, right? git checkout -b c++-concepts origin/c++-concepts >> How will this change the workflow? What's the process for submitting >> changes using git? > > > That depends whether you want to keep it as an SVN branch or switch to a > git-only branch. Both processes are documented in the wiki page: > > http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29 > http://gcc.gnu.org/wiki/GitMirror#Git-only_branches > > If it's unclear, please let me know so I can update the page. I just setup using a git-only branch, so the latter. I set up to push changes to asutton/c++-concepts, so submitted should be visible there. Out of curiosity, how will reviews work? Just walk through the most recently pushed changes on my branch? I should be able to produce diffs to send to Gaby also. I should also be able to use those to patch an SVN checkout and commit from a different repo. Andrew
Re: [PATCH] Redirect calls to non-functions to builtin_unreachable
sHi, On Thu, Jun 20, 2013 at 03:47:11PM +0100, Marcus Shawcroft wrote: > Hi, I've been looking at an issue in mysql compilation which appears > to be due to this patch. > > On 10 May 2013 18:27, Martin Jambor wrote: > > Hi, > > > > as we discover targets of previously indirect calls in ipa-inline and > > ipa-cp, we sometimes figure out that the targets are not a function. > > One typical example is when NULL is passed as a function pointer > > OK, this part makes sense to me. > > > parameter, another is when C++ member-pointer points to a virtual > > function and the overloaded field of the structure which can also hold > > pointers to non-virtual methods contains odd integer constants. > > I'm struggling to understand why such a member-pointer call would be > illegal in a well formed program. > > Attached is a fragment of code that demonstrates the issue I've been > looking at. When compiled at -O3 the 047i.inline dump tells me that: > > ipa-prop: Discovered direct call to non-function in unsigned int > A::foo(unsigned int (H::*)() const) const/11, making it unreachable. > not inlinable: unsigned int A::foo(unsigned int (H::*)() const) > const/11 -> void __builtin_unreachable()/12, function body not > available > > This behavior appears to be the explicit intent of the original patch, > the call to the member function pointer has been replaced with > __builtin_unreachable, but that looks like a legitimate call to me. > What am I missing? Hm, the reason why I did this was that I misremembered that each branch, the one for virtual calls and the one for direct calls. But when I checked dumps, I realized it was not so, there is only one call when the branches join. I'll fix this promptly. Thanks for the report, Martin
Re: [c++-concepts] code review
Jason Merrill writes: | On 06/20/2013 11:22 AM, Gabriel Dos Reis wrote: | > Jason Merrill writes: | > | > | On 06/20/2013 10:17 AM, Andrew Sutton wrote: | > | > It looks like I should be able to switch directly to the c++-concepts | > | > branch. Or is there some configuration that has to happen on the | > | > remote site? | > | | > | The c++-concepts SVN branch won't come in with a clone; you need to | > | add it to the fetch list with | > | | > | git config --add remote.origin.fetch | > | refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts | > | | > | Then you can check out a local branch based on it. | > | > Does that mean I also need to switch to git in order to continue | > maintaining the branch? I would rather stay with SVN for now. | | No, the above is just how you check out the SVN branch under git. Great! Thanks for the clarification. -- Gaby
Re: [c++-concepts] code review
On 06/20/2013 11:22 AM, Gabriel Dos Reis wrote: Jason Merrill writes: | On 06/20/2013 10:17 AM, Andrew Sutton wrote: | > It looks like I should be able to switch directly to the c++-concepts | > branch. Or is there some configuration that has to happen on the | > remote site? | | The c++-concepts SVN branch won't come in with a clone; you need to | add it to the fetch list with | | git config --add remote.origin.fetch | refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts | | Then you can check out a local branch based on it. Does that mean I also need to switch to git in order to continue maintaining the branch? I would rather stay with SVN for now. No, the above is just how you check out the SVN branch under git. I prefer an SVN branch for now. OK. Jason
Re: [c++-concepts] code review
Jason Merrill writes: | On 06/20/2013 10:17 AM, Andrew Sutton wrote: | > It looks like I should be able to switch directly to the c++-concepts | > branch. Or is there some configuration that has to happen on the | > remote site? | | The c++-concepts SVN branch won't come in with a clone; you need to | add it to the fetch list with | | git config --add remote.origin.fetch | refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts | | Then you can check out a local branch based on it. Does that mean I also need to switch to git in order to continue maintaining the branch? I would rather stay with SVN for now. | > How will this change the workflow? What's the process for submitting | > changes using git? | | That depends whether you want to keep it as an SVN branch or switch to | a git-only branch. Both processes are documented in the wiki page: I prefer an SVN branch for now. | | http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29 | http://gcc.gnu.org/wiki/GitMirror#Git-only_branches | | If it's unclear, please let me know so I can update the page. | | Jason -- Gaby
Re: [c++-concepts] code review
Andrew Sutton writes: | That works. I think the current patch addresses all of Jason's comments. OK, that sounds good. | I'll also create a github version of this branch, so can avoid email patches. Well, actually I prefer the email patches because I can read them them right away when I have only email connections (yes, I am one those dinausors who still read emails with emacs remotely from a terminal.) I wish I had the luxury of organizing everything around browsers, but I don't. -- Gaby
Re: [c++-concepts] code review
On 06/20/2013 10:17 AM, Andrew Sutton wrote: It looks like I should be able to switch directly to the c++-concepts branch. Or is there some configuration that has to happen on the remote site? The c++-concepts SVN branch won't come in with a clone; you need to add it to the fetch list with git config --add remote.origin.fetch refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts Then you can check out a local branch based on it. How will this change the workflow? What's the process for submitting changes using git? That depends whether you want to keep it as an SVN branch or switch to a git-only branch. Both processes are documented in the wiki page: http://gcc.gnu.org/wiki/GitMirror#Commit_upstream_.28git-svn.29 http://gcc.gnu.org/wiki/GitMirror#Git-only_branches If it's unclear, please let me know so I can update the page. Jason
[PATCH] Changed type of array notation's struct field
Hello Everyone,
One of the struct field used by array notations (struct inv_list) was
accidentaly set to the type enum rid, but the correct value should be enum
tree_code. This was changed in the following patch. This was causing a warning.
The field is only used by C++ (which patch is still under review). It is
committed as obvious. I am willing to revert this patch or modify it if anyone
has objections.
2013-06-20 Balaji V. Iyer
* array-notation-common.c (find_inv_trees): Removed an unwanted
typecasting.
* c-common.h (struct inv_list::additional_tcodes): Changed type from
enum rid to enum tree_code.
Thanks,
Balaji V. Iyer.
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 3d8f68f..a0f195b 100644
Binary files a/gcc/c-family/ChangeLog and b/gcc/c-family/ChangeLog differ
diff --git a/gcc/c-family/array-notation-common.c b/gcc/c-family/array-notation-
common.c
index 489b67c..c82d7dc 100644
--- a/gcc/c-family/array-notation-common.c
+++ b/gcc/c-family/array-notation-common.c
@@ -484,7 +484,7 @@ find_inv_trees (tree *tp, int *walk_subtrees, void *data)
tree codes such as TARGET_EXPR must be eliminated. These codes are
passed into additional_tcodes and are walked through and checked. */
for (ii = 0; ii < vec_safe_length (i_list->additional_tcodes); ii++)
- if (TREE_CODE (*tp) == (enum rid)(*(i_list->additional_tcodes))[ii])
+ if (TREE_CODE (*tp) == (*(i_list->additional_tcodes))[ii])
*walk_subtrees = 0;
}
return NULL_TREE;
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 8eaf54f..82625d7 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1157,7 +1157,7 @@ struct inv_list
{
vec *list_values;
vec *replacement;
- vec *additional_tcodes;
+ vec *additional_tcodes;
};
/* In array-notation-common.c. */
Re: [PATCH] Redirect calls to non-functions to builtin_unreachable
Hi, I've been looking at an issue in mysql compilation which appears to be due to this patch. On 10 May 2013 18:27, Martin Jambor wrote: > Hi, > > as we discover targets of previously indirect calls in ipa-inline and > ipa-cp, we sometimes figure out that the targets are not a function. > One typical example is when NULL is passed as a function pointer OK, this part makes sense to me. > parameter, another is when C++ member-pointer points to a virtual > function and the overloaded field of the structure which can also hold > pointers to non-virtual methods contains odd integer constants. I'm struggling to understand why such a member-pointer call would be illegal in a well formed program. Attached is a fragment of code that demonstrates the issue I've been looking at. When compiled at -O3 the 047i.inline dump tells me that: ipa-prop: Discovered direct call to non-function in unsigned int A::foo(unsigned int (H::*)() const) const/11, making it unreachable. not inlinable: unsigned int A::foo(unsigned int (H::*)() const) const/11 -> void __builtin_unreachable()/12, function body not available This behavior appears to be the explicit intent of the original patch, the call to the member function pointer has been replaced with __builtin_unreachable, but that looks like a legitimate call to me. What am I missing? Thanks /Marcus foo.cc Description: Binary data
Re: [PATCH] ARMv6-M MI thunk fix
Ping. Cesar On 6/7/13 9:50 AM, Cesar Philippidis wrote: > On 6/6/13 9:00 AM, Richard Earnshaw wrote: >> The pipeline offset is 4 for Thumb2 as well. So at the very least you >> need to explain why your change doesn't apply then as well. > > Yes some context is lost in that comment. Thunks are usually emitted in > ARM mode, except for Thumb-only targets. Is the new comment OK? If so, > please check it in since I do not have SVN write access. > > Thanks, > Cesar > > > 2013-06-07 Julian Brown > Cesar Philippidis > > gcc/ > * config/arm/arm.c (arm_output_mi_thunk): Fix offset for > TARGET_THUMB1_ONLY. >
Fix misoptimization of LTO firefox
Index: ChangeLog
===
--- ChangeLog (revision 200246)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-06-20 Jan Hubicka
+
+ * lto-cgraph.c (input_symtab): Do not set cgraph state.
+
2013-06-20 Joern Rennecke
PR rtl-optimization/57425
Index: lto/ChangeLog
===
--- lto/ChangeLog (revision 200246)
+++ lto/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-06-20 Jan Hubicka
+
+ * lto.c (read_cgraph_and_symbols): Set cgraph state.
+
2013-06-19 Jan Hubicka
* lto-partition.c (add_references_to_partition): Use
Index: lto/lto.c
===
--- lto/lto.c (revision 200246)
+++ lto/lto.c (working copy)
@@ -3362,7 +3362,6 @@ read_cgraph_and_symbols (unsigned nfiles
{
unsigned int i, last_file_ix;
FILE *resolution;
- struct cgraph_node *node;
int count = 0;
struct lto_file_decl_data **decl_data;
void **res;
@@ -3544,14 +3543,7 @@ read_cgraph_and_symbols (unsigned nfiles
}
lto_symtab_merge_symbols ();
ggc_collect ();
-
- /* FIXME: ipa_transforms_to_apply holds list of passes that have optimization
- summaries computed and needs to apply changes. At the moment WHOPR only
- supports inlining, so we can push it here by hand. In future we need to
stream
- this field into ltrans compilation. */
- if (flag_ltrans)
-FOR_EACH_DEFINED_FUNCTION (node)
- node->ipa_transforms_to_apply.safe_push ((ipa_opt_pass)&pass_ipa_inline);
+ cgraph_state = CGRAPH_STATE_IPA_SSA;
timevar_pop (TV_IPA_LTO_CGRAPH_MERGE);
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 200246)
+++ lto-cgraph.c(working copy)
@@ -1451,8 +1451,6 @@ input_symtab (void)
unsigned int j = 0;
struct cgraph_node *node;
- cgraph_state = CGRAPH_STATE_IPA_SSA;
-
while ((file_data = file_data_vec[j++]))
{
const char *data;
Re: [c++-concepts] code review
I didn't know it existed! Even better. Except that I'm not a git expert. I'm reading through the docs on that site while I clone the repo. It looks like I should be able to switch directly to the c++-concepts branch. Or is there some configuration that has to happen on the remote site? How will this change the workflow? What's the process for submitting changes using git? Andrew On Thu, Jun 20, 2013 at 8:57 AM, Jason Merrill wrote: > On 06/20/2013 09:18 AM, Andrew Sutton wrote: >> >> I'll also create a github version of this branch, so can avoid email >> patches. > > > Why there rather than in the gcc.gnu.org git repository? > > http://gcc.gnu.org/wiki/GitMirror > > Jason > -- Andrew Sutton andrew.n.sut...@gmail.com
Re: [PATCH] libitm testsuite fixes
Ping.
Cesar
On 5/30/13 1:02 PM, Cesar Philippidis wrote:
> Here is a patch from our backlog that addresses a libitm issue where
> setting ENABLE_LTO=1 in site.exp causes the following error with dejagnu:
>
> ERROR: (DejaGnu) proc "libitm_target_compile linker_plugin19344.c
> linker_plugin19344.exe executable {{additional_flags=-flto
> -fuse-linker-plugin}}" does not exist.
>
> This problem usually does not occur since the default site.exp does not
> contain ENABLE_LTO=1. This patch has been tested both with and without
> our custom site.exp.
>
> Is this OK for trunk? If so, please check it in since I do not have commit
> rights.
>
> Cesar Philippidis
>
>
> 2013-05-30 Iain Sandoe
> Cesar Philippidis
>
> libitm/
> * testsuite/lib/libitm.exp: Reorder lib loads into dependency order.
> Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
> * testsuite/libitm.c/c.exp: load_gcc_lib gcc-dg.exp.
> * testsuite/libitm.c++/c++.exp: load_gcc_lib gcc-dg.exp.
>
Re: [PATCH] libgomp testsuite fixes
Ping.
Cesar
On 5/30/13 12:59 PM, Cesar Philippidis wrote:
> Here is a patch from our backlog at Mentor Graphics that addresses a
> libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following
> error with dejagnu:
>
> ERROR: (DejaGnu) proc "libgomp_target_compile linker_plugin9263.c
> linker_plugin9263.exe executable {{additional_flags=-flto
> -fuse-linker-plugin}}" does not exist.
>
> This problem usually does not occur since the default site.exp does not
> contain ENABLE_LTO=1. I tested both with and without our custom site.exp.
>
> Is it OK for trunk? If so, please check it in since I do not have commit
> rights.
>
> Cesar Philippidis
>
>
> 2013-05-30 Iain Sandoe
> Cesar Philippidis
>
> libgomp/
> * testsuite/lib/libgomp.exp: Reorder lib loads into dependency order.
> Do not load_gcc_lib gcc-dg.exp and add a comment as to why.
> * testsuite/libgomp.c/c.exp: load_gcc_lib gcc-dg.exp.
> * testsuite/libgomp.fortran/fortran.exp: Likewise.
> * testsuite/libgomp.graphite/graphite.exp: Likewise.
> * testsuite/libgomp.c++/c++.exp: load_gcc_lib gcc-dg.exp.
> Use dg-runtest rather than gfortran-dg-runtest.
>
Re: [c++-concepts] code review
On 06/20/2013 09:18 AM, Andrew Sutton wrote: I'll also create a github version of this branch, so can avoid email patches. Why there rather than in the gcc.gnu.org git repository? http://gcc.gnu.org/wiki/GitMirror Jason
[PATCH][ARM][9/n] Partial IT block deprecation in ARMv8 AArch32 - bitwise ops
Hi all, This patch adjusts the andsi3, iorsi3, xorsi3 patterns for -mrestrict-it. It is done by adding 16-bit alternatives that are fit be cond_exec'd when arm_restrict_it is on. Tested arm-none-eabi on model and qemu with ARMv7 and ARMv8. Also tested as part of the series with bootstrap on a Cortex-A15. Ok for trunk? Thanks, Kyrill 2013-06-20 Kyrylo Tkachov * config/arm/arm.md (arm_andsi3_insn): Add alternatives for 16-bit encoding. (iorsi3_insn): Likewise. (arm_xorsi3): Likewise. 10-bitwise-ops.patch Description: Binary data
Re: [patch] libitm: Fix handling of reentrancy in the HTM fastpath
On Thu, 2013-06-20 at 11:49 +0200, Torvald Riegel wrote: > You're right, that was missing for x86 as well. Please see the updated > second patch that is attached. It additionally checks htm_fastpath to > see whether we are actually using the HTM. This variable is initialized > to the value that htm_init() returns. This should do the right thing I > suppose. Of course you're right too. I totally missed we were already caching that value. Ok, I removed the unneeded call to htm_available() in my htm_transaction_active() and all is well using your second patch. Thanks again! Peter
[PATCH][ARM][8/n] Partial IT block deprecation in ARMv8 AArch32 - mov* patterns and splitters
Hi all, This patch adjusts the mov* patterns in the arm backend to generate code appropriate for -mrestrict-it. The rules are: moves between any two registers are allowed to be in IT blocks. mov immediate are allowed if the immediate is 8-wide and the register is a low register. The splitters that generate explicit cond_exec moves are adjusted to conform to these rules, therefore making this patch self-contained. The "Ts" constraint is introduced which evaluates to the low regs when arm_restrict_it is on, and to the general regs otherwise. Bootstrapped on Cortex-A15 and tested on model and qemu on arm-none-eabi for ARMv7 and ARMv8. Ok for trunk? Thanks, Kyrill 2013-06-20 Kyrylo Tkachov * config/arm/constraints.md (Ts): New constraint. * config/arm/arm.md (arm_movqi_insn): Add alternatives for 16-bit encodings. (compare_scc): Use "Ts" constraint for operand 0. (ior_scc_scc): Likewise. (and_scc_scc): Likewise. (and_scc_scc_nodom): Likewise. (ior_scc_scc_cmp): Likewise for operand 7. (and_scc_scc_cmp): Likewise. * config/arm/thumb2.md (thumb2_movsi_insn): Add alternatives for 16-bit encodings. (thumb2_movhi_insn): Likewise. (thumb2_movsicc_insn): Likewise. (thumb2_and_scc): Take 'and' outside cond_exec. Use "Ts" constraint. (thumb2_negscc): Use "Ts" constraint. Move mvn instruction outside cond_exec block. * config/arm/vfp.md (thumb2_movsi_vfp): Add alternatives for 16-bit encodings. 09-mov-patterns.patch Description: Binary data
[PATCH 2/2] Fix HLE example in manual
From: Andi Kleen
The HLE example in the manual only commits when using bool
for the flag, because __atomic_clear only writes bool, and
HLE requires the acquire and release to match.
So when the example is copied with e.g. an int variable it
does not commit and causes slower than expected performance.
Some people are running into problems because of this.
Switch it over to use __atomic_store.
Also fix a minor typo nearby.
gcc/:
2013-06-13 Andi Kleen
* doc/extend.texi: Dont use __atomic_clear in HLE
example. Fix typo.
---
gcc/doc/extend.texi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index aa3abef..b6f786d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7524,18 +7524,20 @@ End lock elision on a lock variable.
Memory model must be @code{__ATOMIC_RELEASE} or stronger.
@end table
-When a lock acquire fails it's required for good performance to abort
+When a lock acquire fails it is required for good performance to abort
the transaction quickly. This can be done with a @code{_mm_pause}
@smallexample
#include // For _mm_pause
+int lockvar;
+
/* Acquire lock with lock elision */
while (__atomic_exchange_n(&lockvar, 1, __ATOMIC_ACQUIRE|__ATOMIC_HLE_ACQUIRE))
_mm_pause(); /* Abort failed transaction */
...
/* Free lock with lock elision */
-__atomic_clear(&lockvar, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
+__atomic_store(&lockvar, 0, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
@end smallexample
@node Object Size Checking
--
1.8.3
[PATCH 1/2] Improve __atomic_clear/test_and_set documentation
From: Andi Kleen
Document that __atomic_clear and __atomic_test_and_set should
only be used with bool.
gcc/:
2013-06-13 Andi Kleen
* doc/extend.texi: Document that __atomic_clear and
__atomic_test_and_set should only be used with bool.
---
gcc/doc/extend.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1e1f8b3..aa3abef 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7438,6 +7438,8 @@ This built-in function performs an atomic test-and-set
operation on
the byte at @code{*@var{ptr}}. The byte is set to some implementation
defined nonzero ``set'' value and the return value is @code{true} if and only
if the previous contents were ``set''.
+It should be only used for operands of type bool or atomic_flag. For
+other types only part of the value may be set.
All memory models are valid.
@@ -7447,6 +7449,10 @@ All memory models are valid.
This built-in function performs an atomic clear operation on
@code{*@var{ptr}}. After the operation, @code{*@var{ptr}} contains 0.
+It should be only used for operands of type bool or atomic_flag and
+in conjunction with __atomic_test_and_set.
+For other types it may only clear partially. If the type is not bool
+prefer using @code{__atomic_store}.
The valid memory model variants are
@code{__ATOMIC_RELAXED}, @code{__ATOMIC_SEQ_CST}, and
--
1.8.3
Re: [c++-concepts] code review
That works. I think the current patch addresses all of Jason's comments. I'll also create a github version of this branch, so can avoid email patches. On Thu, Jun 20, 2013 at 8:09 AM, Gabriel Dos Reis wrote: > Jason Merrill writes: > > | On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote: > | > As I discussed > | > with Andrew a couple of weeks ago, I have been holding back the > | > merge from trunk because he has these patch series in the queue. > | > | Incidentally, since the code is going onto a branch, we don't really > | need to delay checkins based on code review; I'd actually rather > | review the code from within git than from an email patch. > > Makes sense. Andrew, you can check in what you have now, and refine > based on all other comments. I won't have network connection until > tonight; at that point I will do the merge from trunk. We don't want to > have the branch too old compared to the trunk. > > -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com
Re: [PATCH, x86] Use vector moves in memmove expanding
Hi, I added two tests to verify we generate vector instructions when vector_loop is used. Is the patch ok with that change? Thanks, Michael On 5 June 2013 18:10, Michael Zolotukhin wrote: > I'll prepare some tests shortly, > What about the rest questions? > > Thanks, Michael > > On 15 May 2013 19:45, H.J. Lu wrote: >> On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin >> wrote: >>> Hi HJ, You use Pmode as the largest integer mode. Is word_mode better than Pmode since word_mode is DI and Pmode may be SI for x32. >>> I updated the patch to use word_mode instead of Pmode. Bootstrap, >>> make check and Specs2000 are ok. >>> >>> Thanks, Michael >>> >>> On 14 May 2013 19:55, H.J. Lu wrote: On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin wrote: > Hi, > I attached an updated version of the patch. Looks like the 64-bit issue > is > resolved in it (now a vector mode is explicitly chosen instead of TI- or > another integer mode). Also, some of remarks are fixed in it - some > others are still not changed, because I don't know what to do with them > right > now (see my questions in the previous letter). > > Could you take a look at the patch? > > I checked it on i386/x86_64 bootstrap and make check, and on > Specs2000/2006 > (I checked only stability). > You use Pmode as the largest integer mode. Is word_mode better than Pmode since word_mode is DI and Pmode may be SI for x32. >> >> You should include tests to verify that it works as >> expected. >> >> >> -- >> H.J. > > > > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation. memmov-4.patch Description: Binary data
Re: [c++-concepts] code review
Jason Merrill writes: | On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote: | > As I discussed | > with Andrew a couple of weeks ago, I have been holding back the | > merge from trunk because he has these patch series in the queue. | | Incidentally, since the code is going onto a branch, we don't really | need to delay checkins based on code review; I'd actually rather | review the code from within git than from an email patch. Makes sense. Andrew, you can check in what you have now, and refine based on all other comments. I won't have network connection until tonight; at that point I will do the merge from trunk. We don't want to have the branch too old compared to the trunk. -- Gaby
Re: [c++-concepts] code review
On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote: As I discussed with Andrew a couple of weeks ago, I have been holding back the merge from trunk because he has these patch series in the queue. Incidentally, since the code is going onto a branch, we don't really need to delay checkins based on code review; I'd actually rather review the code from within git than from an email patch. Jason
Re: [PATCH] Improve folding of bitwise ops feeding conditionals for single bit types
On 06/20/2013 04:49 AM, Andreas Schwab wrote:
Jeff Law writes:
+/* { dg-final { scan-tree-dump-times "Replaced" 8 "forwprop1"} } */
$ grep -c Replaced forwprop-28.c.022t.forwprop1
16
;; Function test (test, funcdef_no=0, decl_uid=1388, symbol_order=0)
Replaced 'rotate_7 == 0' with '_6 == 0'
Replaced '_6 == 0' with 'code_5(D) != 22'
Target?
Give me enough information and I'll gladly take a look. Give me junk
and I'll ignore.
jeff
Re: [PATCH, trunk, PR57358] Avoid IPA-CP analysis if attribute optimize precludes it
Hi,
On Thu, Jun 20, 2013 at 01:32:38PM +0200, Jan Hubicka wrote:
> >
> > 2013-06-11 Martin Jambor
> >
> > PR tree-optimization/57358
> > * ipa-prop.c (ipa_func_spec_opts_forbid_analysis_p): New function.
> > (ipa_compute_jump_functions_for_edge): Bail out if it returns true.
> > (ipa_analyze_params_uses): Generate pessimistic info when true.
> >
> > testsuite
> > * gcc.dg/ipa/pr57358.c: New test.
> >
> > Index: src/gcc/ipa-prop.c
> > ===
> > --- src.orig/gcc/ipa-prop.c
> > +++ src/gcc/ipa-prop.c
> > @@ -78,6 +78,21 @@ struct ipa_cst_ref_desc
> >
> > static alloc_pool ipa_refdesc_pool;
> >
> > +/* Return true if DECL_FUNCTION_SPECIFIC_OPTIMIZATION of the decl
> > associated
> > + with NODE should prevent us from analyzing it for the purposes of
> > IPA-CP. */
> > +
> > +static bool
> > +ipa_func_spec_opts_forbid_analysis_p (struct cgraph_node *node)
> > +{
> > + tree fs_opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (node->symbol.decl);
> > + struct cl_optimization *os;
> > +
> > + if (!fs_opts)
> > +return false;
> > + os = TREE_OPTIMIZATION (fs_opts);
> > + return !os->x_optimize || !os->x_flag_ipa_cp;
> > +}
>
> Hmm, somewhat ugly, but I suppose it is as ugly as it needs to be.
> I wonder about the other IPA passes. Do we want to always ignore them?
Well, I suppose that if we wanted to truly support the optimize
attribute in its full strength and generality (or at least make an
effort to do so), all IPA passes would need to check for their flag(s)
their. In fact, this should be even more ugly if done really
properly. -fno-indirect-inlinig should be checked in
ipa_analyze_call_uses, for example, -fno-devirtualize at various other
places... And of course, we should probably never just bail out but
mark the flags in the IPA structures instead because they are used by
both IPA-CP and inlining and perhaps disabling the features in one
should not disable it another...
...so I just decided this has never worked and I was not going to
spend too much time fixing it. I hesitated about the
os->x_flag_ipa_cp test, but eventually thought it might be useful for
us when debugging so I kept it. Still, publicly I'd continue saying
that IPA passes cannot be adjusted by the optimize attribute.
> How the ICE happens? Is it because we don't do the analysis?
No, we do, and we ask alias oracle about stuff even though there are
no VDEFs and VUSEs which segfaults. IPA passes just have to be
careful not to ICE on -O0 functions.
Thanks,
Martin
Re: [patch] set MULTIARCH_DIRNAME for multilib architectures
Am 13.06.2013 11:42, schrieb Richard Sandiford: > "Bernhard Reutner-Fischer" writes: >> On 12 June 2013 20:20:50 Richard Sandiford >> wrote: >>> Matthias Klose writes: Index: config/mips/t-linux64 === --- config/mips/t-linux64 (revision 200012) +++ config/mips/t-linux64 (working copy) @@ -24,3 +24,13 @@ ../lib32$(call >>> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) + +ifneq (,$(findstring abin32,$(target))) +MULTIARCH_DIRNAME = $(call >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) +else +ifneq (,$(findstring abi64,$(target))) +MULTIARCH_DIRNAME = $(call >>> if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) +else +MULTIARCH_DIRNAME = $(call >>> if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) +endif +endif >>> >>> findstring seems a bit fragile for a full triple. I think it would >>> be better to have something similar to the current MIPS_SOFT definition: >>> >>> MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, >>> $(target_cpu_default)) $(filter soft, $(with_float))),soft) >>> >>> but for ABIs. It could then also take with_abi into account. >>> Maybe something like: >>> >>> MIPS_ABI = $(or $(with_abi), \ >>> $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ >>> $(target_cpu_default)), n32), \ >>> o32) >>> >>> (completely untested). >> >> Bikeshedding: >> Doko would know, but ISTR that $(or) did not exist in make-3.80 which is >> currently the minimum prerequisite, fwiw. > > Gah, that's a pity. Thanks for the catch though. Maybe firstword > would be OK instead. > > I see I also fell into the usual ABI trap. It wouldn't have affected > the use in this patch, but the default ought to be "32" rather than "o32". the define is in tm_defines, not target_cpu_default. MIPS_ABI = $(or $(with_abi), \ $(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \ $(tm_defines)), n32), \ 32) However I can't see yet how this should be used. Maybe Aurelian could come up with a tested version of this patch? Matthias
Re: [PATCH, trunk, PR57358] Avoid IPA-CP analysis if attribute optimize precludes it
>
> 2013-06-11 Martin Jambor
>
> PR tree-optimization/57358
> * ipa-prop.c (ipa_func_spec_opts_forbid_analysis_p): New function.
> (ipa_compute_jump_functions_for_edge): Bail out if it returns true.
> (ipa_analyze_params_uses): Generate pessimistic info when true.
>
> testsuite
> * gcc.dg/ipa/pr57358.c: New test.
>
> Index: src/gcc/ipa-prop.c
> ===
> --- src.orig/gcc/ipa-prop.c
> +++ src/gcc/ipa-prop.c
> @@ -78,6 +78,21 @@ struct ipa_cst_ref_desc
>
> static alloc_pool ipa_refdesc_pool;
>
> +/* Return true if DECL_FUNCTION_SPECIFIC_OPTIMIZATION of the decl associated
> + with NODE should prevent us from analyzing it for the purposes of IPA-CP.
> */
> +
> +static bool
> +ipa_func_spec_opts_forbid_analysis_p (struct cgraph_node *node)
> +{
> + tree fs_opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (node->symbol.decl);
> + struct cl_optimization *os;
> +
> + if (!fs_opts)
> +return false;
> + os = TREE_OPTIMIZATION (fs_opts);
> + return !os->x_optimize || !os->x_flag_ipa_cp;
> +}
Hmm, somewhat ugly, but I suppose it is as ugly as it needs to be.
I wonder about the other IPA passes. Do we want to always ignore them?
How the ICE happens? Is it because we don't do the analysis?
Honza
[testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
Hi,
for Android:
FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 (test for excess errors)
Excess errors:
<>/gcc/testsuite/g++.dg/tls/thread_local4.C:31:26: error:
'pthread_testcancel' was not declared in this scope
<>/gcc/testsuite/g++.dg/tls/thread_local4.C:40:24: error:
'pthread_cancel' was not declared in this scope
the same for thread_local4g.C.
from http://www.kandroid.org/ndk/docs/system/libc/OVERVIEW.html
"pthread_cancel() will not be supported in Bionic, because doing this
would involve making the C library significantly bigger for very
little benefit.
<...>"
The following patch switches those tests off for Android.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b8073d1..d217e4d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-06-19 Alexander Ivchenko
+
+ * g++.dg/tls/thread_local4.C: Disable test for Android.
+ * g++.dg/tls/thread_local4g.C: Ditto.
+
2013-06-11 Tobias Burnus
PR fortran/57508
diff --git a/gcc/testsuite/g++.dg/tls/thread_local4.C
b/gcc/testsuite/g++.dg/tls/thread_local4.C
index acf1cae..cc1a35a 100644
--- a/gcc/testsuite/g++.dg/tls/thread_local4.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local4.C
@@ -1,6 +1,7 @@
// Test for cleanups with pthread_cancel.
-// { dg-do run }
+// There is no support of pthread_cancel in Android.
+// { dg-do run { target { ! *-*-android* } } }
// { dg-require-effective-target c++11 }
// { dg-require-effective-target tls_runtime }
// { dg-require-effective-target pthread }
diff --git a/gcc/testsuite/g++.dg/tls/thread_local4g.C
b/gcc/testsuite/g++.dg/tls/thread_local4g.C
index f5bc3ff..756c6a2 100644
--- a/gcc/testsuite/g++.dg/tls/thread_local4g.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local4g.C
@@ -1,6 +1,7 @@
// Test for cleanups with pthread_cancel.
-// { dg-do run }
+// There is no support of pthread_cancel in Android.
+// { dg-do run { target { ! *-*-android* } } }
// { dg-require-effective-target c++11 }
// { dg-require-effective-target tls_runtime }
// { dg-require-effective-target pthread }
is it ok for trunk?
--Alexander
[PATCH] Speedup streamer_read_uhwi
This speeds up streamer_read_uhwi (top in mozilla LTO profile) by
delaying the section overrun check and inlining streamer_read_uchar
manually, performing CSE and optimizing the 1-byte case.
LTO bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2013-06-20 Richard Biener
* data-streamer-in.c (streamer_read_uhwi): Optimize single
byte case, inline streamer_read_uchar and defer section
overrun check.
Index: gcc/data-streamer-in.c
===
*** gcc/data-streamer-in.c (revision 200189)
--- gcc/data-streamer-in.c (working copy)
*** bp_unpack_string (struct data_in *data_i
*** 120,137
unsigned HOST_WIDE_INT
streamer_read_uhwi (struct lto_input_block *ib)
{
! unsigned HOST_WIDE_INT result = 0;
! int shift = 0;
unsigned HOST_WIDE_INT byte;
! while (true)
{
! byte = streamer_read_uchar (ib);
! result |= (byte & 0x7f) << shift;
! shift += 7;
! if ((byte & 0x80) == 0)
! return result;
}
}
--- 120,152
unsigned HOST_WIDE_INT
streamer_read_uhwi (struct lto_input_block *ib)
{
! unsigned HOST_WIDE_INT result;
! int shift;
unsigned HOST_WIDE_INT byte;
+ unsigned int p = ib->p;
+ unsigned int len = ib->len;
! const char *data = ib->data;
! result = data[p++];
! if ((result & 0x80) != 0)
{
! result &= 0x7f;
! shift = 7;
! do
! {
! byte = data[p++];
! result |= (byte & 0x7f) << shift;
! shift += 7;
! }
! while ((byte & 0x80) != 0);
}
+
+ /* We check for section overrun after the fact for performance reason. */
+ if (p > len)
+ lto_section_overrun (ib);
+
+ ib->p = p;
+ return result;
}
Re: [PATCH, 4.8, PR57358] Check if optimizing in parm_ref_data_preserved_p
> Hi, > > this is the simplest fix for the PR which happens because there is no > VDEF on a stmt if a particular function is not optimized. I'd like to > fix the bug with it on the branch. Bootstrapped and tested on > x86_64-linux. OK? > > Thanks, > > Martin > > > 2013-06-11 Martin Jambor > > PR tree-optimization/57358 > * ipa-prop.c (parm_ref_data_preserved_p): Always return true when > not optimizing. Seems to make sense, OK, Honza
Re: [PATCH, PR 57539] Fix refdesc remapping during inlining
> Hi,
>
> PR 57539 revealed two problems with remapping reference descriptors
> during cloning of trees of inlined call graph nodes. First, when
> indirect inlining is involved, we happily remove the reference
> descriptor itself by calling ipa_free_edge_args_substructures in
> ipa_propagate_indirect_call_infos. Second, the current remapping code
> does not work because the global.inlined_to field of the destination
> caller is not yet set.
>
> The patch below fixes the first problem by not calling the freeing
> function and the second one by making cgraph_clone_node set the
> required field prior to calling any duplication hooks (which is the
> only place where we have the pair of corresponding source and
> destination edge at our disposal so the duplication/remapping has to
> happen there). I have also shortened the lists of corresponding
> references and cleared up the search loop a little.
>
> I'll post a testcase in a separate patch. This one bootstrapped and
> passed testsuite on x86_64-linux without any issues. OK for trunk?
>
> Thanks,
>
> Martin
>
>
> 2013-06-10 Martin Jambor
>
> PR tree-optimization/57539
> * cgraphclones.c (cgraph_clone_node): Add parameter new_inlined_to, set
> global.inlined_to of the new node to it. All callers changed.
> * ipa-inline-transform.c (clone_inlined_nodes): New variable
> inlining_into, pass it to cgraph_clone_node.
> * ipa-prop.c (ipa_propagate_indirect_call_infos): Do not call
> ipa_free_edge_args_substructures.
> (ipa_edge_duplication_hook): Only add edges from inlined nodes to
> rdesc linked list. Do not assert rdesc edges have inlined caller.
> Assert we have found an rdesc in the rdesc list.
OK,
thanks
Honza
>
> Index: src/gcc/cgraph.h
> ===
> --- src.orig/gcc/cgraph.h
> +++ src/gcc/cgraph.h
> @@ -707,7 +707,7 @@ struct cgraph_edge * cgraph_clone_edge (
> unsigned, gcov_type, int, bool);
> struct cgraph_node * cgraph_clone_node (struct cgraph_node *, tree,
> gcov_type,
> int, bool, vec,
> - bool);
> + bool, struct cgraph_node *);
> tree clone_function_name (tree decl, const char *);
> struct cgraph_node * cgraph_create_virtual_clone (struct cgraph_node
> *old_node,
> vec,
> Index: src/gcc/cgraphclones.c
> ===
> --- src.orig/gcc/cgraphclones.c
> +++ src/gcc/cgraphclones.c
> @@ -167,13 +167,19 @@ cgraph_clone_edge (struct cgraph_edge *e
> function's profile to reflect the fact that part of execution is handled
> by node.
> When CALL_DUPLICATOIN_HOOK is true, the ipa passes are acknowledged about
> - the new clone. Otherwise the caller is responsible for doing so later. */
> + the new clone. Otherwise the caller is responsible for doing so later.
> +
> + If the new node is being inlined into another one, NEW_INLINED_TO should
> be
> + the outline function the new one is (even indirectly) inlined to. All
> hooks
> + will see this in node's global.inlined_to, when invoked. Can be NULL if
> the
> + node is not inlined. */
>
> struct cgraph_node *
> cgraph_clone_node (struct cgraph_node *n, tree decl, gcov_type count, int
> freq,
> bool update_original,
> vec redirect_callers,
> -bool call_duplication_hook)
> +bool call_duplication_hook,
> +struct cgraph_node *new_inlined_to)
> {
>struct cgraph_node *new_node = cgraph_create_empty_node ();
>struct cgraph_edge *e;
> @@ -195,6 +201,7 @@ cgraph_clone_node (struct cgraph_node *n
>new_node->symbol.externally_visible = false;
>new_node->local.local = true;
>new_node->global = n->global;
> + new_node->global.inlined_to = new_inlined_to;
>new_node->rtl = n->rtl;
>new_node->count = count;
>new_node->frequency = n->frequency;
> @@ -307,7 +314,7 @@ cgraph_create_virtual_clone (struct cgra
>
>new_node = cgraph_clone_node (old_node, new_decl, old_node->count,
> CGRAPH_FREQ_BASE, false,
> - redirect_callers, false);
> + redirect_callers, false, NULL);
>/* Update the properties.
> Make clone visible only within this translation unit. Make sure
> that is not weak also.
> Index: src/gcc/ipa-inline-transform.c
> ===
> --- src.orig/gcc/ipa-inline-transform.c
> +++ src/gcc/ipa-inline-transform.c
> @@ -132,6 +132,13 @@ void
> clone_inlined_nodes (struct cgraph_edge *e, bool duplicate,
>bool update_original, int *overall_size)
> {
> + struct cgraph_node *inlining_into;
> +
> + if (e->caller-
Re: [PATCH] Improve folding of bitwise ops feeding conditionals for single bit types
Jeff Law writes:
> +/* { dg-final { scan-tree-dump-times "Replaced" 8 "forwprop1"} } */
$ grep -c Replaced forwprop-28.c.022t.forwprop1
16
;; Function test (test, funcdef_no=0, decl_uid=1388, symbol_order=0)
Replaced 'rotate_7 == 0' with '_6 == 0'
Replaced '_6 == 0' with 'code_5(D) != 22'
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH, ARM] Reintroduce minipool ranges for zero-extension insn patterns
On Tue, 18 Jun 2013 17:10:37 +0100
Richard Earnshaw wrote:
> On 18/06/13 16:42, Julian Brown wrote:
> > Hi,
> >
> > The following patch removed pool_range/neg_pool_range attributes
> > from several instructions as a cleanup, which I believe to have been
> > incorrect:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01036.html
> >
> > On a Mentor-local branch, this caused problems with instructions
> > like:
> >
> > (insn 77 53 87 (set (reg:SI 8 r8 [orig:197 s.4 ] [197])
> > (zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI ("*.LC0")
> > [flags 0x2]) [7 S2 A16]))) [...] 161 {*arm_zero_extendhisi2_v6}
> > (nil))
> >
> > The reasoning behind the cleanup was that the instructions in
> > question have no immediate constraints -- but the minipool code is
> > used for more than just immediates, e.g. in the above case where a
> > symbol reference ("m") is loaded.
> >
> > I don't have a test case for the problem on mainline at present,
> > but I believe it is still a latent bug. Tested with the default
> > multilibs (ARM & Thumb mode) on arm-none-eabi, with no regressions.
> > (The patch has also been tested with more multilibs on our local
> > branches for a while, and I did ensure previously that it did not
> > adversely affect Bernd's patch linked above.)
> >
> > OK to apply?
> >
>
> Pushing extending loads (particularly sign-extending loads) into the
> minipools adversely affects freedom of pool placement (since the
> offset ranges are limited).
>
> And they shouldn't be happening anyway. I really don't think this is
> the right solution to the problem you have.
How about this as a fix instead? IIUC, all the instances of this bug
that have been reported relate to insns following the pattern:
(set (reg) (sign/zero_extend:SI (symbol_ref:QI/HI)))
where the symbol_ref is a match_operand with an "m" constraint. These
kinds of addresses are explicitly permitted by
arm_legitimate_address_outer_p and thumb2_legitimate_address_p by the
last clause in the functions, "if (GET_MODE_CLASS (mode) != MODE_FLOAT
&& ...", etc.
So, I think the obvious thing to do is to forbid sub-SImode-sized
quantities in that clause. Perhaps tellingly, the thumb1 version of the
function already forbids sizes other than 4 for the mode size in the
equivalent clause. For non-Thumb1, we probably want to retain DImode
(etc.) minipool entries.
The change to generated code for a re-reduced version of the testcase
from:
https://bugzilla.redhat.com/show_bug.cgi?id=927565
(attached), for an insn which breaks before the attached patch is
applied, 210r.reload:
before:
(insn 7 30 33 2 (set (reg:SI 12 ip [orig:110 D.4194 ] [110])
(zero_extend:SI (mem/u/c:QI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
S1 A8]))) minipool.c:11 182 {*arm_zero_extendqisi2_v6}
(nil))
after (with a reload):
(insn 221 30 7 2 (set (reg:SI 0 r0)
(symbol_ref/u:SI ("*.LC0") [flags 0x2])) minipool.c:11 197
{*arm_movsi_insn}
(nil))
(insn 7 221 33 2 (set (reg:SI 12 ip [orig:110 D.4194 ] [110])
(zero_extend:SI (mem/u/c:QI (reg:SI 0 r0) [0 S1 A8]))) minipool.c:11
182 {*arm_zero_extendqisi2_v6}
(nil))
(Compiled with -march=armv7-a -O2.)
Tested cross to arm-none-eabi, default & mthumb multilibs. I also
removed some additional pool_range/neg_pool_ranges from similar
extension instructions, for consistency.
OK to apply?
Thanks,
Julian
ChangeLog
gcc/
* config/arm/arm.c (arm_legitimate_address_outer_p)
(thumb2_legitimate_address_p): Don't allow symbol refs with mode
size smaller than a word.
* config/arm/arm.md (thumb1_zero_extendqisi2, *arm_extendhisi2)
(*arm_extendhisi2_v6, *arm_extendqihi_insn, *arm_extendqisi)
(*arm_extendqisi_v6): Remove pool_range/neg_pool_range attributes.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c (revision 200204)
+++ gcc/config/arm/arm.c (working copy)
@@ -5947,6 +5947,7 @@ arm_legitimate_address_outer_p (enum mac
#endif
else if (GET_MODE_CLASS (mode) != MODE_FLOAT
+ && GET_MODE_SIZE (mode) >= UNITS_PER_WORD
&& code == SYMBOL_REF
&& CONSTANT_POOL_ADDRESS_P (x)
&& ! (flag_pic
@@ -6022,6 +6023,7 @@ thumb2_legitimate_address_p (enum machin
}
else if (GET_MODE_CLASS (mode) != MODE_FLOAT
+ && GET_MODE_SIZE (mode) >= UNITS_PER_WORD
&& code == SYMBOL_REF
&& CONSTANT_POOL_ADDRESS_P (x)
&& ! (flag_pic
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md (revision 200204)
+++ gcc/config/arm/arm.md (working copy)
@@ -5432,8 +5432,7 @@
#
ldrb\\t%0, %1"
[(set_attr "length" "4,2")
- (set_attr "type" "alu_shift,load_byte")
- (set_attr "pool_range" "*,32")]
+ (set_attr "type" "alu_shift,load_byte")]
)
(define_insn "*thumb1_zero_extendqisi2_v6"
@@ -5700,9 +5699,7 @@
ldr%(sh%)\\t%0, %1"
[(set_attr "length" "8,4")
(set_attr "type" "alu_shift,load_byte")
- (s
Re: [Patch, Fortran] PR57633 - Fix EOL handling with \r in list-directed I/O
On Thu, Jun 20, 2013 at 12:11 PM, Tobias Burnus wrote:
> gfortran failed to correctly read the file
>line1,1,
>line2
> with DOS (\r\n) line endings. As the code already set EOL for "\r",
> finish_list_read didn't call eat_line. Result: The attempt to read "line2"
> actually accessed the last byte of line one, namely "\n", which it regarded
> as zero-sized string.
>
> That's fixed by the patch to next_char.
>
> eat_separator is a separate issue and unrelated to the PR. I also failed to
> create a test case for it. In any case, I regard the following as wrong:
>
> case '\r':
> dtp->u.p.at_eol = 1;
> ...
>if (n != '\n')
> {
> unget_char (dtp, n);
> break;
>
> As the code explicitly does not regard "\r" as EOL in this case, I believe
> EOL shouldn't be set here.
>
> (Recall, Unix (MacOS X, Linux, ...) have '\n' while DOS/Windows has "\r\n".
> While '\r' as line break exists (old Macs, pre MacOS X), gfortran does not
> support formatted I/O with "\r" record markers.)
>
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
Ok, thanks.
--
Janne Blomqvist
[PATCH] Fix PR57584
We have to be careful to not end up inserting expressions with
abnormal SSA names. Thus the following makes niter analysis
more careful what it puts into number-of-iteration expressions.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-06-20 Richard Biener
PR tree-optimization/57584
* tree-ssa-loop-niter.c (expand_simple_operations): Avoid including
SSA names into the expanded expression that take part in
abnormal coalescing.
* gcc.dg/torture/pr57584.c: New testcase.
Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c (revision 200189)
--- gcc/tree-ssa-loop-niter.c (working copy)
*** expand_simple_operations (tree expr)
*** 1514,1519
--- 1514,1526
if (gimple_code (stmt) != GIMPLE_ASSIGN)
return expr;
+ /* Avoid expanding to expressions that contain SSA names that need
+ to take part in abnormal coalescing. */
+ ssa_op_iter iter;
+ FOR_EACH_SSA_TREE_OPERAND (e, stmt, iter, SSA_OP_USE)
+ if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (e))
+ return expr;
+
e = gimple_assign_rhs1 (stmt);
code = gimple_assign_rhs_code (stmt);
if (get_gimple_rhs_class (code) == GIMPLE_SINGLE_RHS)
Index: gcc/testsuite/gcc.dg/torture/pr57584.c
===
*** gcc/testsuite/gcc.dg/torture/pr57584.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr57584.c (working copy)
***
*** 0
--- 1,73
+ /* { dg-do compile } */
+
+ typedef int int32_t __attribute__ ((__mode__ (__SI__)));
+ typedef unsigned char uint8_t;
+ typedef unsigned long int uintptr_t;
+ typedef uint8_t scm_t_uint8;
+ typedef int32_t scm_t_int32;
+ typedef uintptr_t scm_t_uintptr;
+ typedef scm_t_uintptr scm_t_bits;
+ typedef struct scm_unused_struct {
+ } *SCM;
+ enum scm_tc8_tags {
+ scm_tc8_flag = 4 + 0x00, scm_tc8_char = 4 + 0x08, scm_tc8_unused_0 =
4 + 0x10, scm_tc8_unused_1 = 4 + 0x18 };
+ struct __jmp_buf_tag {
+ };
+ typedef struct __jmp_buf_tag jmp_buf[1];
+ typedef struct scm_t_cell {
+ } scm_t_cell;
+ struct scm_prompt_registers {
+ jmp_buf regs;
+ };
+ enum {
+ SCM_VM_APPLY_HOOK, SCM_VM_PUSH_CONTINUATION_HOOK,
SCM_VM_POP_CONTINUATION_HOOK, SCM_VM_NEXT_HOOK,
SCM_VM_ABORT_CONTINUATION_HOOK, SCM_VM_RESTORE_CONTINUATION_HOOK,
SCM_VM_NUM_HOOKS, };
+ typedef SCM (*scm_t_vm_engine) (SCM vm, SCM program, SCM *argv, int nargs);
+ struct scm_vm {
+ scm_t_uint8 *ip;
+ SCM *sp;
+ SCM *fp;
+ int engine;
+ int trace_level;
+ };
+ static SCM vm_regular_engine (SCM vm, SCM program, SCM *argv, int nargs) {
+ }
+ static SCM vm_debug_engine (SCM vm, SCM program, SCM *argv, int nargs) {
+ register scm_t_uint8 *ip ;
+ register SCM *sp ;
+ register SCM *fp ;
+ struct scm_vm *vp = ((struct scm_vm *) scm_t_bits) (0?
(*(SCM*)0=SCM *)((scm_t_cell *) (((scm_t_bits) (0? (*(SCM*)0=vm):
(((vm [((1))]))): (((SCM *)((scm_t_cell *) (((scm_t_bits) (0?
(*(SCM*)0=vm): (((vm [((1))]));
+ static const void **jump_table_pointer = ((void *)0);
+ register const void **jump_table asm ("r12");
+ if (__builtin_expect ((!jump_table_pointer), 0)) {
+ jump_table_pointer[0] = &&l_nop;
+ }
+ l_nop:
+ {
+ SCM *old_sp;
+ scm_t_int32 n;
+ old_sp = sp;
+ sp = (fp - 1) + n;
+ if (old_sp < sp) {
+ while (old_sp < sp) *++old_sp = ((SCM) ((9)) << 8) +
scm_tc8_flag;
+ }
+ {
+ { if (__builtin_expect ((vp->trace_level > 0), 0)) { { vp->ip =
ip; vp->sp = sp; vp->fp = fp; }; vm_dispatch_hook (vm, SCM_VM_NEXT_HOOK); } };
+ };
+ }
+ {
+ SCM k, prompt;
+ if ((_setjmp (((struct scm_prompt_registers*)scm_t_bits) (0?
(*(SCM*)0=SCM *)((scm_t_cell *) (((scm_t_bits) (0?
(*(SCM*)0=prompt): (((prompt [((2))]))): (((SCM *)((scm_t_cell
*) (((scm_t_bits) (0? (*(SCM*)0=prompt): (((prompt
[((2))]))->regs))) {
+ { ip = vp->ip; sp = vp->sp; fp = vp->fp; };
+ { { if (__builtin_expect ((vp->trace_level > 0), 0)) { { vp->ip =
ip; vp->sp = sp; vp->fp = fp; }; vm_dispatch_hook (vm, SCM_VM_NEXT_HOOK); } };
; goto *jump_table[(*ip++) & ((1<<8)-1)]; };
+ }
+
+ if (__builtin_expect ((vp->trace_level > 0), 0)) { { vp->ip = ip;
vp->sp = sp; vp->fp = fp; }; vm_dispatch_hook (vm, SCM_VM_NEXT_HOOK); } ;
+
+ }
+ }
+ static const scm_t_vm_engine vm_engines[] = {
+ vm_regular_engine, vm_debug_engine };
+ SCM scm_c_vm_run (SCM vm, SCM program, SCM *argv, int nargs) {
+ struct scm_vm *vp = ((struct scm_vm *) scm_t_bits) (0?
(*(SCM*)0=SCM *)((scm_t_cell *) (((scm_t_bits) (0? (*(SCM*)0=vm):
(((vm [((1))]))): (((SCM *)((scm_t_cell *) (((scm_t_bits) (0?
Re: [patch] libitm: Fix handling of reentrancy in the HTM fastpath
On Wed, 2013-06-19 at 22:13 -0500, Peter Bergner wrote:
> On Thu, 2013-06-20 at 00:51 +0200, Torvald Riegel wrote:
> > On Wed, 2013-06-19 at 14:43 -0500, Peter Bergner wrote:
> > >> I'm having trouble seeing why/when _ITM_inTransaction() is
> > >> returning something other than inIrrevocableTransaction. I'll see if I
> > >> can
> > >> determine why and will report back.
> > >
> > > Ok, we return outsideTransaction because the nesting level (tx->nesting)
> > > is zero.
> >
> > That's a second bug in libitm, sorry. Can you try with the attached
> > patch additionally to the previous one? Thanks!
>
> Ok, with this patch, plus adding a powerpc implementation of
> htm_transaction_active(), reentrant.c now executes correctly
> on both HTM and non-HTM hardware for me. Thanks for all of
> your help with this!
>
> I'd still like to hear from Andreas, whether the reentrant.c test case
> with both patches, now works on S390.
>
> I'll note unlike your x86 htm_transaction_active() implementation,
> my implementation has to check for htm_available() first before
> executing the htm instruction which tells me whether I'm in transaction
> state or not, otherwise I'll get a SIGILL on non-HTM hardware.
> Unfortunately, my htm_available() call uses getauxval() to query
> the AUXV for a hwcap bit. Is there a place I can stash the result
> of the first call, so that subsequent calls use the cached value?
> Normally, I could use a static var, but I doubt that is what we want
> to do in static inline functions.
You're right, that was missing for x86 as well. Please see the updated
second patch that is attached. It additionally checks htm_fastpath to
see whether we are actually using the HTM. This variable is initialized
to the value that htm_init() returns. This should do the right thing I
suppose.
Torvald
commit c8352d4d9fa5cfa3453a61c581956835de9753e5
Author: Torvald Riegel
Date: Thu Jun 20 00:46:59 2013 +0200
libitm: Handle HTM fastpath in status query functions.
diff --git a/libitm/config/x86/target.h b/libitm/config/x86/target.h
index 77b627f..063c09e 100644
--- a/libitm/config/x86/target.h
+++ b/libitm/config/x86/target.h
@@ -125,6 +125,13 @@ htm_abort_should_retry (uint32_t begin_ret)
{
return begin_ret & _XABORT_RETRY;
}
+
+/* Returns true iff a hardware transaction is currently being executed. */
+static inline bool
+htm_transaction_active ()
+{
+ return _xtest() != 0;
+}
#endif
diff --git a/libitm/query.cc b/libitm/query.cc
index 5707321..39a35b3 100644
--- a/libitm/query.cc
+++ b/libitm/query.cc
@@ -43,6 +43,15 @@ _ITM_libraryVersion (void)
_ITM_howExecuting ITM_REGPARM
_ITM_inTransaction (void)
{
+#if defined(USE_HTM_FASTPATH)
+ // If we use the HTM fastpath, we cannot reliably detect whether we are
+ // in a transaction because this function can be called outside of
+ // a transaction and thus we can't deduce this by looking at just the serial
+ // lock. This function isn't used in practice currently, so the easiest
+ // way to handle it is to just abort.
+ if (htm_fastpath && htm_transaction_active())
+htm_abort();
+#endif
struct gtm_thread *tx = gtm_thr();
if (tx && (tx->nesting > 0))
{
@@ -58,6 +67,11 @@ _ITM_inTransaction (void)
_ITM_transactionId_t ITM_REGPARM
_ITM_getTransactionId (void)
{
+#if defined(USE_HTM_FASTPATH)
+ // See ITM_inTransaction.
+ if (htm_fastpath && htm_transaction_active())
+htm_abort();
+#endif
struct gtm_thread *tx = gtm_thr();
return (tx && (tx->nesting > 0)) ? tx->id : _ITM_noTransactionId;
}
[Patch, Fortran, committed] Don't set FL_VARIABLE twice
Follow up to http://gcc.gnu.org/ml/fortran/2013-06/msg00027.html - for
some reason this part of the patch got lost.
Committed as Rev. 200234.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 200233)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,14 +1,18 @@
+2013-06-20 Tobias Burnus
+
+ * resolve.c (get_temp_from_expr): Don't set FL_VARIABLE twice.
+
2013-06-17 Tobias Burnus
* gfortran.h (gfc_option_t): Add fpe_summary.
* gfortran.texi (_gfortran_set_options): Update.
* invoke.texi (-ffpe-summary): Add doc.
* lang.opt (ffpe-summary): Add flag.
* options.c (gfc_init_options, gfc_handle_option): Handle it.
(gfc_handle_fpe_option): Renamed from gfc_handle_fpe_trap_option,
also handle fpe_summary.
* trans-decl.c (create_main_function): Update
_gfortran_set_options call.
2013-06-15 Mikael Morin
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 200233)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -9300,29 +9300,28 @@ get_temp_from_expr (gfc_expr *e, gfc_nam
tmp->n.sym->attr.flavor = FL_VARIABLE;
if (as)
{
tmp->n.sym->as = gfc_copy_array_spec (as);
if (!ref)
ref = e->ref;
if (as->type == AS_DEFERRED)
tmp->n.sym->attr.allocatable = 1;
}
else
tmp->n.sym->attr.dimension = 0;
gfc_set_sym_referenced (tmp->n.sym);
- gfc_add_flavor (&tmp->n.sym->attr, FL_VARIABLE, name, NULL);
gfc_commit_symbol (tmp->n.sym);
e = gfc_lval_expr_from_sym (tmp->n.sym);
/* Should the lhs be a section, use its array ref for the
temporary expression. */
if (aref && aref->type != AR_FULL)
{
gfc_free_ref_list (e->ref);
e->ref = gfc_copy_ref (ref);
}
return e;
}
[Patch, Fortran] PR57633 - Fix EOL handling with \r in list-directed I/O
gfortran failed to correctly read the file
line1,1,
line2
with DOS (\r\n) line endings. As the code already set EOL for "\r",
finish_list_read didn't call eat_line. Result: The attempt to read
"line2" actually accessed the last byte of line one, namely "\n", which
it regarded as zero-sized string.
That's fixed by the patch to next_char.
eat_separator is a separate issue and unrelated to the PR. I also failed
to create a test case for it. In any case, I regard the following as wrong:
case '\r':
dtp->u.p.at_eol = 1;
...
if (n != '\n')
{
unget_char (dtp, n);
break;
As the code explicitly does not regard "\r" as EOL in this case, I
believe EOL shouldn't be set here.
(Recall, Unix (MacOS X, Linux, ...) have '\n' while DOS/Windows has
"\r\n". While '\r' as line break exists (old Macs, pre MacOS X),
gfortran does not support formatted I/O with "\r" record markers.)
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-06-20 Tobias Burnus
PR fortran/57633
* io/list_read.c (next_char, eat_separator): Don't set EOL for \r.
2013-06-20 Tobias Burnus
PR fortran/57633
* gfortran.dg/list_read_11.f90: New.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index c8a1bdfc..82a98a5 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -235,21 +235,21 @@ next_char (st_parameter_dt *dtp)
}
}
}
else
{
c = fbuf_getc (dtp->u.p.current_unit);
if (c != EOF && is_stream_io (dtp))
dtp->u.p.current_unit->strm_pos++;
}
done:
- dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF);
+ dtp->u.p.at_eol = (c == '\n' || c == EOF);
return c;
}
/* Push a character back onto the input. */
static void
unget_char (st_parameter_dt *dtp, int c)
{
dtp->u.p.last_char = c;
@@ -327,21 +327,20 @@ eat_separator (st_parameter_dt *dtp)
case ';':
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
break;
case '/':
dtp->u.p.input_complete = 1;
break;
case '\r':
- dtp->u.p.at_eol = 1;
if ((n = next_char(dtp)) == EOF)
return LIBERROR_END;
if (n != '\n')
{
unget_char (dtp, n);
break;
}
/* Fall through. */
case '\n':
dtp->u.p.at_eol = 1;
--- /dev/null 2013-06-20 10:08:42.876937873 +0200
+++ gcc/gcc/testsuite/gfortran.dg/list_read_11.f90 2013-06-20 10:55:13.329549458 +0200
@@ -0,0 +1,38 @@
+! { dg-do run }
+! { dg-options "-fbackslash" }
+!
+! PR fortran/57633
+!
+program teststuff
+ implicit none
+ integer::a
+ character(len=10)::s1,s2
+
+ open(11,file="testcase.txt",form='unformatted',access='stream',status='new')
+ write(11) 'line1,1,\r\nline2'
+ close(11)
+
+ open(11,file="testcase.txt",form='formatted')
+ s1 = repeat('x', len(s1))
+ a = 99
+ read(11,*)s1,a
+ if (s1 /= "line1" .or. a /= 1) call abort()
+
+ s1 = repeat('x', len(s1))
+ read(11,"(a)")s1
+ close(11,status="delete")
+ if (s1 /= "line2") call abort()
+
+
+ open(11,file="testcase.txt",form='unformatted',access='stream',status='new')
+ write(11) 'word1\rword2,\n'
+ close(11)
+
+ open(11,file="testcase.txt",form='formatted')
+ s1 = repeat('x', len(s1))
+ s2 = repeat('x', len(s1))
+ read(11,*)s1,s2
+ close(11,status="delete")
+ if (s1 /= "word1") call abort()
+ if (s2 /= "word2") call abort()
+end program teststuff
Re: RFA: Fix rtl-optimization/57425
On Wed, Jun 19, 2013 at 9:58 PM, Joern Rennecke
wrote:
> Quoting Michael Matz :
>
>> That's not good. You now have different order of parameters between
>> anti_dependence and canon_anti_dependence. That will be mightily
>> confusing, please instead change the caller. Currently these predicates
>> take their arguments in the order of the corresponding instructions, that
>> should better be retained:
>>
>> true_dependence: write-then-(depending)read
>> anti_dependence: read-then-(clobbering)write
>> write_dependence: write-then-(clobbering)write
>
>
> All right, attached is the patch with the arguments in instruction-order.
> Again, bootstrapped/regtested on i686-pc-linux-gnu .
Ok.
Thanks,
Richard.
> 2013-06-19 Joern Rennecke
>
> PR rtl-optimization/57425
> PR rtl-optimization/57569
> * alias.c (write_dependence_p): Remove parameters mem_mode and
> canon_mem_addr. Add parameters x_mode, x_addr and x_canonicalized.
> Changed all callers.
> (canon_anti_dependence): Get comments and semantics in sync.
> Add parameter mem_canonicalized. Changed all callers.
> * rtl.h (canon_anti_dependence): Update prototype.
>
> Index: alias.c
> ===
> --- alias.c (revision 200133)
> +++ alias.c (working copy)
> @@ -156,8 +156,9 @@ static int insert_subset_children (splay
> static alias_set_entry get_alias_set_entry (alias_set_type);
> static bool nonoverlapping_component_refs_p (const_rtx, const_rtx);
> static tree decl_for_component_ref (tree);
> -static int write_dependence_p (const_rtx, enum machine_mode, rtx,
> const_rtx,
> - bool, bool);
> +static int write_dependence_p (const_rtx,
> + const_rtx, enum machine_mode, rtx,
> + bool, bool, bool);
>
> static void memory_modified_1 (rtx, const_rtx, void *);
>
> @@ -2555,20 +2556,22 @@ canon_true_dependence (const_rtx mem, en
>
> /* Returns nonzero if a write to X might alias a previous read from
> (or, if WRITEP is true, a write to) MEM.
> - If MEM_CANONCALIZED is nonzero, CANON_MEM_ADDR is the canonicalized
> - address of MEM, and MEM_MODE the mode for that access. */
> + If X_CANONCALIZED is true, then X_ADDR is the canonicalized address of
> X,
> + and X_MODE the mode for that access.
> + If MEM_CANONICALIZED is true, MEM is canonicalized. */
>
> static int
> -write_dependence_p (const_rtx mem, enum machine_mode mem_mode,
> - rtx canon_mem_addr, const_rtx x,
> - bool mem_canonicalized, bool writep)
> +write_dependence_p (const_rtx mem,
> + const_rtx x, enum machine_mode x_mode, rtx x_addr,
> + bool mem_canonicalized, bool x_canonicalized, bool
> writep)
> {
> - rtx x_addr, mem_addr;
> + rtx mem_addr;
>rtx base;
>int ret;
>
> - gcc_checking_assert (mem_canonicalized ? (canon_mem_addr != NULL_RTX)
> - : (canon_mem_addr == NULL_RTX && mem_mode ==
> VOIDmode));
> + gcc_checking_assert (x_canonicalized
> + ? (x_addr != NULL_RTX && x_mode != VOIDmode)
> + : (x_addr == NULL_RTX && x_mode == VOIDmode));
>
>if (MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem))
> return 1;
> @@ -2593,17 +2596,21 @@ write_dependence_p (const_rtx mem, enum
>if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
> return 1;
>
> - x_addr = XEXP (x, 0);
>mem_addr = XEXP (mem, 0);
> - if (!((GET_CODE (x_addr) == VALUE
> -&& GET_CODE (mem_addr) != VALUE
> -&& reg_mentioned_p (x_addr, mem_addr))
> - || (GET_CODE (x_addr) != VALUE
> - && GET_CODE (mem_addr) == VALUE
> - && reg_mentioned_p (mem_addr, x_addr
> + if (!x_addr)
> {
> - x_addr = get_addr (x_addr);
> - mem_addr = get_addr (mem_addr);
> + x_addr = XEXP (x, 0);
> + if (!((GET_CODE (x_addr) == VALUE
> +&& GET_CODE (mem_addr) != VALUE
> +&& reg_mentioned_p (x_addr, mem_addr))
> + || (GET_CODE (x_addr) != VALUE
> + && GET_CODE (mem_addr) == VALUE
> + && reg_mentioned_p (mem_addr, x_addr
> + {
> + x_addr = get_addr (x_addr);
> + if (!mem_canonicalized)
> + mem_addr = get_addr (mem_addr);
> + }
> }
>
>base = find_base_term (mem_addr);
> @@ -2619,17 +2626,16 @@ write_dependence_p (const_rtx mem, enum
> GET_MODE (mem)))
> return 0;
>
> - x_addr = canon_rtx (x_addr);
> - if (mem_canonicalized)
> -mem_addr = canon_mem_addr;
> - else
> + if (!x_canonicalized)
> {
> - mem_addr = canon_rtx (mem_addr);
> - mem_mode = GET_MODE (mem);
> + x_addr = canon_rtx (x_addr);
> + x_mode = GET_MODE (x);
> }
> + if (!mem_canonicalized)
> +mem_addr = canon_rtx (mem_addr);
>
> - if ((ret = memrefs_conflict_p (GET_MO
Re: [PATCH] PR32219, weak hidden reference segfault [PING]
Ping again? On 13/6/11 5:20 PM, Bernhard Reutner-Fischer wrote: > ping, CCing middle-end maintainers for review. > > On 31 May 2013 10:13, Chung-Lin Tang wrote: >> On 13/5/15 8:12 PM, Richard Sandiford wrote: >>> Chung-Lin Tang writes: On 13/5/10 6:37 PM, Richard Sandiford wrote: > Chung-Lin Tang writes: >> +case UNSPEC: >> + /* Reach for a contained symbol. */ >> + return nonzero_address_p (XVECEXP (x, 0, 0)); > > I don't think this is safe. UNSPECs really are unspecified :-), > so we can't assume that (unspec X) is nonzero simply because X is. Attached is a modified patch (not yet tested but just for demonstration) with a more specific test, hopefully regarded as more safe. The point is in recognizing (const (unspec [symbol] XYZ)) offsets in PIC references, which seems quite idiomatic across all targets by now. >>> >>> I agree this is safer. However, there used to be some ports that >>> use (plus pic_offset_table_rtx (symbol_ref X)) -- i.e. without an unspec -- >>> to represent a PIC reference to X. That always seemed semantically wrong, >>> since you're not actually adding the address of X and the PIC register, >>> but the patch wouldn't handle that case correctly. >> >> Well I can't help those targets then, but at least nothing will be >> changed for them by this patch. It will just continue to return 'true'. >> >>> An alternative might be to remove the pic_offset_table_rtx case altogether >>> and rely on targetm.delegitimize_address instead. FWIW, I'd prefer that >>> if it works, but it's not me you need to convince. :-) >> >> Like we discussed below, I think the direction should be towards making >> things more machine-independent, rather then pushing more into the backend. >> I would suggest that this probably means there should be a new, more specific construct in RTL to represent relocation values of this kind, instead of (const (unspec)) serving an unofficial role; possibly some real support for reasoning about PIC references could also be considered. >>> >>> Yeah, maybe we could try to introduce some target-independent knowledge >>> of certain reloc types, a bit like the generic BFD_RELOC_*s in bfd. >> >> >> FWIW, I've ran tests on the newer patch on i686-linux, with no >> regressions. Testcase has been moved to gcc.dg/torture by recommendation >> of Bernhard. If any of the RTL maintainers can give an eye of merciful >> approval, this old PR could be resolved :) >> >> Thanks, >> Chung-Lin >>
