Re: [PATCH C++] document order of C++ ctors and attribute constructor is unspecified

[Jason Merrill]

On Wed, Mar 15, 2017 at 6:59 PM, Martin Sebor  wrote:
> In bug 52477 - Wrong initialization order?  attribute constructor
> vs static data access, the reporter expects C++ objects with static
> storage duration to have their ctors called in the same order as
> those of functions declared with attribute constructor interleaved
> with them.
>
> In his comment on the bug Richard opines that relying on the order
> is undefined.  The attached patch updates the manual to make this
> clear.

I disagree with that comment, and have added one of my own, but I
think your patch is appropriate for GCC 7 since we aren't going to fix
it in this release.

Jason

Re: [PATCH 2/5][P1][tree-optimization/71437] Record more equivalences in some cases

[Jeff Law]

On 03/15/2017 09:17 PM, Jeff Law wrote:


Patch #3 will remove handle_dominating_asserts from the core of the jump
threading code and push it into VRP's callbacks where it should always
have been.

As a side effect it causes some code which was previously only used for
threading from VRP to be used unconditionally.  It's actually a good
thing as that code will find more jump threads.  But in one case  the
resulting code is tougher for tree-ssa-uninit.c to handle and we get a
false positive uninit warning.

As it turns out for that case we're better off improving DOM slightly
which allows DOM to simplify the test even further.  This patch
implements the DOM improvement so that we don't see a regression when
patch #3 is installed.

The particular case we're looking to improve looks like

t = a | b;
if (t == 0)
...

In the TRUE arm we know that a must be zero and b must be zero.
Discovering those equivalences allows DOM to do a better job for the
uninit testcase from the testsuite.

There's clearly more that could be done with this code, but I didn't
want to take it any further than was needed to address the regression
that would be caused by patch #3.

Bootstrapped and regression tested on x86_64-linux-gnu.  Installing on
the trunk.  I'll be testing this in combination with patch #1 tomorrow
on ppc64le to get additional coverage.

Jeff

Whoops.  This time with the patch.

Jeff
PR tree-optimization/71437
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): New function.
(record_temporary_equivalences): Use it.

diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index ad71269..0ebe892 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -691,6 +691,33 @@ back_propagate_equivalences (tree lhs, edge e,
 BITMAP_FREE (domby);
 }
 
+/* Record NAME has the value zero and if NAME was set from a BIT_IOR_EXPR
+   recurse into both operands recording their values as zero too.  */
+
+static void
+derive_equivalencs_from_bit_ior (tree name, const_and_copies *const_and_copies)
+{
+  if (TREE_CODE (name) == SSA_NAME)
+{
+  tree value = fold_convert (TREE_TYPE (name), integer_zero_node);
+
+  /* This records the equivalence for the toplevel object.  */
+  record_equality (name, value, const_and_copies);
+
+  /* And we can recurse into each operand to potentially find more
+equivalences.  */
+  gimple *def_stmt = SSA_NAME_DEF_STMT (name);
+  if (is_gimple_assign (def_stmt)
+ && gimple_assign_rhs_code (def_stmt) == BIT_IOR_EXPR)
+   {
+ derive_equivalencs_from_bit_ior (gimple_assign_rhs1 (def_stmt),
+  const_and_copies);
+ derive_equivalencs_from_bit_ior (gimple_assign_rhs2 (def_stmt),
+  const_and_copies);
+   }
+}
+}
+
 /* Record into CONST_AND_COPIES and AVAIL_EXPRS_STACK any equivalences implied
by traversing edge E (which are cached in E->aux).
 
@@ -711,7 +738,28 @@ record_temporary_equivalences (edge e,
   /* If we have 0 = COND or 1 = COND equivalences, record them
 into our expression hash tables.  */
   for (i = 0; edge_info->cond_equivalences.iterate (i, ); ++i)
-   avail_exprs_stack->record_cond (eq);
+   {
+ avail_exprs_stack->record_cond (eq);
+
+ /* If the condition is testing that X == 0 is true or X != 0 is false
+and X is set from a BIT_IOR_EXPR, then we can record equivalences
+for the operands of the BIT_IOR_EXPR (and recurse on those).  */
+ tree op0 = eq->cond.ops.binary.opnd0;
+ tree op1 = eq->cond.ops.binary.opnd1;
+ if (TREE_CODE (op0) == SSA_NAME && integer_zerop (op1))
+   {
+ enum tree_code code = eq->cond.ops.binary.op;
+ if ((code == EQ_EXPR && eq->value == boolean_true_node)
+ || (code == NE_EXPR && eq->value == boolean_false_node))
+   derive_equivalencs_from_bit_ior (op0, const_and_copies);
+
+ /* TODO: We could handle BIT_AND_EXPR in a similar fashion
+recording that the operands have a nonzero value.  */
+
+ /* TODO: We can handle more cases here, particularly when OP0 is
+known to have a boolean range.  */
+   }
+   }
 
   tree lhs = edge_info->lhs;
   if (!lhs || TREE_CODE (lhs) != SSA_NAME)

[PATCH 2/5][P1][tree-optimization/71437] Record more equivalences in some cases

[Jeff Law]

Patch #3 will remove handle_dominating_asserts from the core of the jump 
threading code and push it into VRP's callbacks where it should always 
have been.


As a side effect it causes some code which was previously only used for 
threading from VRP to be used unconditionally.  It's actually a good 
thing as that code will find more jump threads.  But in one case  the 
resulting code is tougher for tree-ssa-uninit.c to handle and we get a 
false positive uninit warning.


As it turns out for that case we're better off improving DOM slightly 
which allows DOM to simplify the test even further.  This patch 
implements the DOM improvement so that we don't see a regression when 
patch #3 is installed.


The particular case we're looking to improve looks like

t = a | b;
if (t == 0)
...

In the TRUE arm we know that a must be zero and b must be zero. 
Discovering those equivalences allows DOM to do a better job for the 
uninit testcase from the testsuite.


There's clearly more that could be done with this code, but I didn't 
want to take it any further than was needed to address the regression 
that would be caused by patch #3.


Bootstrapped and regression tested on x86_64-linux-gnu.  Installing on 
the trunk.  I'll be testing this in combination with patch #1 tomorrow 
on ppc64le to get additional coverage.


Jeff

[PATCH 1/5][P1][tree-optimization/71437] Refactoring to avoid duplication

[Jeff Law]

As mentioned in the cover message, this is strictly a refactoring patch.

lookup_avail_expr should always have been a class member of the 
available expression stack.  That (of course) allows it to be used by 
any instance of the class (which we'll take advantage of later from 
within VRP's instance of jump threading).  We bring along vuse_eq as a 
dependency.


Similarly for record_cond which knows some internals of the hash table 
implementation.


record_conditions doesn't directly use the hash tables, but builds up a 
vector of conditions in hashable_expr form.  We're going to want to use 
this within the VRP threading instance as well.  We bring along 
build_and_record_new_cond as a dependency.


These routines all move with no significant change in their 
implementation except for avoiding dom_valueize, which we open code in 
the one spot it was previously used.



This has been bootstrapped and regression tested on x86_64-linux-gnu. 
Installing on the trunk.  I'll be doing a bootstrap and regression test 
of patch #1+#2 tomorrow on ppc64le for additional testing coverage.


Jeff
PR tree-optimization/71437
* tree-ssa-dom.c (struct cond_equivalence): Moved from here into
tree-ssa-scopedtables.
(lookup_avail_expr, build_and_record_new_cond): Likewise.
(record_conditions, record_cond, vuse_eq): Likewise.
(record_edge_info): Adjust to API tweak of record_conditions.
(simplify_stmt_for_jump_threading): Similarly for lookup_avail_expr.
(record_temporary_equivalences, optimize_stmt): Likewise.
(eliminate_redundant_computations): Likewise.
(record_equivalences_from_stmt): Likewise.
* tree-ssa-scopedtables.c: Include options.h and params.h.
(vuse_eq): New function, moved from tree-ssa-dom.c
(build_and_record_new_cond): Likewise.
(record_conditions): Likewise.  Accept vector of conditions rather
than edge_equivalence structure for first argument.
for the first argument.
(avail_exprs_stack::lookup_avail_expr): New member function, moved
from tree-ssa-dom.c.
(avail_exprs_stack::record_cond): Likewise.
* tree-ssa-scopedtables.h (struct cond_equivalence): Moved here
from tree-ssa-dom.c.
(avail_exprs_stack): Add new member functions lookup_avail_expr
and record_cond.
(record_conditions): Declare.


diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 2ec3f97..ad71269 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -48,15 +48,6 @@ along with GCC; see the file COPYING3.  If not see
 
 /* This file implements optimizations on the dominator tree.  */
 
-/* Structure for recording known values of a conditional expression
-   at the exits from its block.  */
-
-struct cond_equivalence
-{
-  struct hashable_expr cond;
-  tree value;
-};
-
 /* Structure for recording edge equivalences.
 
Computing and storing the edge equivalences instead of creating
@@ -103,9 +94,6 @@ static struct opt_stats_d opt_stats;
 static edge optimize_stmt (basic_block, gimple_stmt_iterator,
   class const_and_copies *,
   class avail_exprs_stack *);
-static tree lookup_avail_expr (gimple *, bool, class avail_exprs_stack *,
-  bool = true);
-static void record_cond (cond_equivalence *, class avail_exprs_stack *);
 static void record_equality (tree, tree, class const_and_copies *);
 static void record_equivalences_from_phis (basic_block);
 static void record_equivalences_from_incoming_edge (ba:sic_block,
@@ -175,148 +163,6 @@ free_all_edge_infos (void)
 }
 }
 
-/* Build a cond_equivalence record indicating that the comparison
-   CODE holds between operands OP0 and OP1 and push it to **P.  */
-
-static void
-build_and_record_new_cond (enum tree_code code,
-   tree op0, tree op1,
-   vec *p,
-  bool val = true)
-{
-  cond_equivalence c;
-  struct hashable_expr *cond = 
-
-  gcc_assert (TREE_CODE_CLASS (code) == tcc_comparison);
-
-  cond->type = boolean_type_node;
-  cond->kind = EXPR_BINARY;
-  cond->ops.binary.op = code;
-  cond->ops.binary.opnd0 = op0;
-  cond->ops.binary.opnd1 = op1;
-
-  c.value = val ? boolean_true_node : boolean_false_node;
-  p->safe_push (c);
-}
-
-/* Record that COND is true and INVERTED is false into the edge information
-   structure.  Also record that any conditions dominated by COND are true
-   as well.
-
-   For example, if a < b is true, then a <= b must also be true.  */
-
-static void
-record_conditions (struct edge_info *edge_info, tree cond, tree inverted)
-{
-  tree op0, op1;
-  cond_equivalence c;
-
-  if (!COMPARISON_CLASS_P (cond))
-return;
-
-  op0 = TREE_OPERAND (cond, 0);
-  op1 = TREE_OPERAND (cond, 1);
-
-  switch (TREE_CODE (cond))
-{
-case LT_EXPR:
-case GT_EXPR:
-  if (FLOAT_TYPE_P (TREE_TYPE (op0)))
-   {

[PATCH 0/5 ][P1] [PR tree-optimization/71437]

[Jeff Law]

So as noted in the PR, we're failing to discover an important jump 
thread during threading from VRP.  This is a case where the symbolic 
range is actually more useful than constants in the range.


There's some talk of improving this in VRP for gcc-8, but in the mean 
time, fixing this by improving threading is feasible and actually takes 
a useful step in the long term plan.


The central idea here is to allow the VRP instance of jump threading to 
record conditions from ASSERT_EXPRs into the available expression table. 
 We can see the symbolic ranges from those expressions.  Of course, 
there's some bits to put in place first.


Patch #1 is pure refactoring/movement.  A couple routines are turned 
into member functions of the scoped hash tables and another is kept as 
normal function but moved into a more natural location which also makes 
it available in DOM and VRP.


Patch #2 improves DOM's ability to discover implied equivalences when an 
object is known to have the value 0.  This avoids a regression due to 
changes in patch #3.  There's more that could be done here.  But I've 
tried to keep the scope of what's changing small due to being in stage4.


Patch #3 pushes ASSERT_EXPR handling out of the core of the threader and 
into callbacks used by VRP.  It should have been done this way to begin 
with.  It's so painfully obvious 10+ years later.


Patch #4 turns random order walk for threading from VRP into a domwalk 
and refactors some common code from VRP/DOM into the threader itself.


Patch #5 allows recording equivalences from ASSERT_EXPRs and looking up 
objects in the expression hash table in the VRP threading callback.  At 
which point we're done.  Not surprisingly, with the infrastructure in 
place patch #5 is actually trivial.


The set looks much bigger than it really is.  That's largely because of 
refactoring that's going on.


Commit plan:

I'm committing patches #1 and #2 together and giving them ~12hrs to 
simmer.  The improvements in DOM could possibly trigger the need to 
adjust expected outputs of tests.  I haven't seen in the need on x86.


I'm going to be doing some ppc64le testing tomorrow.  It's been 
surprisingly hard to get a machine from our testpool.


Assuming no issues with #1/#2, then I'll proceed to #3/#4.  I don't have 
any real concerns with #3/#4, but I want to isolate them from #5 just in 
case #5 needs further testsuite tweakage.  Assuming all goes well, #5 
would be committed Friday.



Jeff

[PATCH rs6000] Fix PR79951, ICE for unrecognizable insn with -mno-cmpb

[Pat Haugen]

The define_expand for copysign3 will call
gen_copysign3_fcpsgn if either TARGET_CMPB || VECTOR_UNIT_VSX_P
(mode) are true, but gen_copysign3_fcpsgn is missing the
check of VECTOR_UNIT_VSX_P (mode) which results in an
unrecognizable insn ICE. This is fixed with the following patch.

Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?
Ok for backport to GCC 5/6 branches after testing?

-Pat


2017-03-15  Pat Haugen  

PR target/79951
* config/rs6000/rs6000.md (copysign3_fcpsgn): Test
for VECTOR_UNIT_VSX_P (mode) too.

testsuite/ChangeLog:
2017-03-15  Pat Haugen  

* gcc.target/powerpc/pr79951.c: New.



Index: config/rs6000/rs6000.md
===
--- config/rs6000/rs6000.md (revision 246180)
+++ config/rs6000/rs6000.md (working copy)
@@ -4831,7 +4831,7 @@ (define_insn "copysign3_fcpsgn"
(unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" ",")
  (match_operand:SFDF 2 "gpc_reg_operand" ",")]
 UNSPEC_COPYSIGN))]
-  "TARGET__FPR && TARGET_CMPB"
+  "TARGET__FPR && (TARGET_CMPB || VECTOR_UNIT_VSX_P (mode))"
   "@
fcpsgn %0,%2,%1
xscpsgndp %x0,%x2,%x1"
Index: testsuite/gcc.target/powerpc/pr79951.c
===
--- testsuite/gcc.target/powerpc/pr79951.c  (nonexistent)
+++ testsuite/gcc.target/powerpc/pr79951.c  (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" }
{ "-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -S -mno-cmpb" } */
+
+float testf (float x, float y)
+{
+  return __builtin_copysignf (x, y);
+}
+

patch to fix PR80017

[Vladimir Makarov]

The following patch fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80017

The patch was successfully bootstrapped and tested on x86-64, ppc64, and 
aarch64.


Committed as rev. 246181.

Index: ChangeLog
===
--- ChangeLog	(revision 246180)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2017-03-15  Vladimir Makarov  
+
+	PR target/80017
+	* lra-constraints.c (process_alt_operands): Increase reject for
+	reloading an input/output operand.
+
 2017-03-15  Michael Meissner  
 
 	PR target/79038
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 246180)
+++ lra-constraints.c	(working copy)
@@ -2713,6 +2713,15 @@ process_alt_operands (int only_alternati
 
 	  if (MEM_P (op) && offmemok)
 		addr_losers++;
+	  else if (curr_static_id->operand[nop].type == OP_INOUT)
+		{
+		  if (lra_dump_file != NULL)
+		fprintf
+		  (lra_dump_file,
+		   "%d Input/Output reload: reject+=%d\n",
+		   nop, LRA_LOSER_COST_FACTOR);
+		  reject += LRA_LOSER_COST_FACTOR;
+		}
 	}
 
 	  if (early_clobber_p && ! scratch_p)

Re: [v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Jonathan Wakely]

On 16/03/17 00:43 +0200, Ville Voutilainen wrote:

On 16 March 2017 at 00:31, Jonathan Wakely  wrote:

  emplace(_Args&&... __args)
  {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));



Can we avoid the branch in any_cast to check the stored type?
We know it's the right type, because we just stored it.


While I would hope the compiler to be smart enough to realize some of
that (we are passing in
this), the other branches might not be so easy. But certainly, we can
axe every one of the extraneous
branches, like in the attached amendment.


And then we don't need the forward declarations of any and any_ast,
right?

OK for trunk like that, thanks.

[PATCH C++] document order of C++ ctors and attribute constructor is unspecified

[Martin Sebor]

In bug 52477 - Wrong initialization order?  attribute constructor
vs static data access, the reporter expects C++ objects with static
storage duration to have their ctors called in the same order as
those of functions declared with attribute constructor interleaved
with them.

In his comment on the bug Richard opines that relying on the order
is undefined.  The attached patch updates the manual to make this
clear.

Jason, can you please review it for 7.0?

Martin
PR c++/52477 - Wrong initialization order? __attribute__((constructor)) vs static data access

gcc/ChangeLog:

	PR c++/52477
	* doc/extend.texi (attribute constructor): Mention order of C++ ctors.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 143a7b7..159f1be 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2510,7 +2510,11 @@ if you have a constructor that allocates a resource and a destructor
 that deallocates the same resource, both functions typically have the
 same priority.  The priorities for constructor and destructor
 functions are the same as those specified for namespace-scope C++
-objects (@pxref{C++ Attributes}).
+objects (@pxref{C++ Attributes}).  However, the order in which
+constructors for C++ objects with static storage duration and functions
+decorated with attribute @code{constructor} are invoked is unspecified.
+In mixed declarations, attribute @code{init_priority} can be used to
+impose a specific ordering.
 
 @item deprecated
 @itemx deprecated (@var{msg})

Re: [v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Ville Voutilainen]

On 16 March 2017 at 00:31, Jonathan Wakely  wrote:
>>   emplace(_Args&&... __args)
>>   {
>> __do_emplace<_Decay<_ValueType>>
>>   (std::forward<_Args>(__args)...);
>> +   return *(std::any_cast<_Decay<_ValueType>>(this));
>
>
> Can we avoid the branch in any_cast to check the stored type?
> We know it's the right type, because we just stored it.

While I would hope the compiler to be smart enough to realize some of
that (we are passing in
this), the other branches might not be so easy. But certainly, we can
axe every one of the extraneous
branches, like in the attached amendment.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index fff13d9..ef6efa5 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -278,7 +278,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
-   return *(std::any_cast<_Decay<_ValueType>>(this));
+   any::_Arg __arg;
+   this->_M_manager(any::_Op_access, this, &__arg);
+   return *static_cast<_Decay<_ValueType>*>(__arg._M_obj);
   }
 
 /// Emplace with an object created from @p __il and @p __args as
@@ -292,7 +294,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__do_emplace<_Decay<_ValueType>, _Up>
  (__il, std::forward<_Args>(__args)...);
-   return *(std::any_cast<_Decay<_ValueType>>(this));
+   any::_Arg __arg;
+   this->_M_manager(any::_Op_access, this, &__arg);
+   return *static_cast<_Decay<_ValueType>*>(__arg._M_obj);
   }
 
 // modifiers
diff --git a/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc 
b/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
index 2d2b3d3..8e3ca73 100644
--- a/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
@@ -26,5 +26,5 @@ void test01()
   using std::any_cast;
 
   const any y(1);
-  any_cast(y); // { dg-error "invalid static_cast" "" { target { *-*-* } 
} 461 }
+  any_cast(y); // { dg-error "invalid static_cast" "" { target { *-*-* } 
} 465 }
 }

Re: [v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Jonathan Wakely]

On 16/03/17 00:21 +0200, Ville Voutilainen wrote:

Tested on Linux-x64.

2017-03-16  Ville Voutilainen  

   Implement LWG 2857, {variant,optional,any}::emplace should
   return the constructed value.
   * include/std/any (any_cast(any*)): Forward-declare.
   (emplace(_Args&&...)): Change the return type and
   return a reference to the constructed value.
   (emplace(initializer_list<_Up>, _Args&&...)): Likewise.
   * include/std/optional (emplace(_Args&&...)): Likewise.
   (emplace(initializer_list<_Up>, _Args&&...)): Likewise.
   * include/std/variant (emplace<_Tp>(_Args&&...)): Likewise.
   (emplace<_Tp>(initializer_list<_Up>, _Args&&...)): Likewise.
   (emplace<_Np>(_Args&&...)): Likewise.
   (emplace<_Np>(initializer_list<_Up>, _Args&&...)): Likewise.
   * testsuite/20_util/any/assign/emplace.cc: Add tests for
   checking the return value of emplace.
   * testsuite/20_util/any/misc/any_cast_neg.cc: Adjust.
   * testsuite/20_util/optional/assignment/6.cc: Add tests for
   checking the return value of emplace.
   * testsuite/20_util/variant/run.cc: Likewise.



diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index e807617..fff13d9 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -74,6 +74,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   *  An @c any object's state is either empty or it stores a contained object
   *  of CopyConstructible type.
   */
+  class any;
+  template
+inline _ValueType* any_cast(any* __any) noexcept;
+
  class any
  {
// Holds either pointer to a heap object or the contained object itself.
@@ -268,18 +272,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

/// Emplace with an object created from @p __args as the contained object.
template 
-  typename __any_constructible&,
   _Decay<_ValueType>, _Args&&...>::type
  emplace(_Args&&... __args)
  {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));


Can we avoid the branch in any_cast to check the stored type?
We know it's the right type, because we just stored it.

[PATCH], PR target/71294, Fix compiler segfault for reload & power8

[Michael Meissner]

This patch is a simpler approach to fixing PR 71294, then I proposed last year.

The core of the problem is when we are creating V2DI/V2DF vectors via a splat
operation, the predicate for the second argument allows memory addresses, GPR
registers as well as VSX registers, but when we compile for power8, the
constraints only allow memory addresses and VSX registers.

I fixed this by allowing a GPR -> VSX splat operation and after reload,
splitting it to the appropriate scalar direct move and then XXPERMDI to form
the vector.  I did look at changing the splat_input_operation predicate to not
allow GPR registers in this case, but reload generates worse code in this case.

I have built compilers on a little endian Power8 system (64-bit only), big
endian Power8 system (64-bit only) and big endian Power7 system (32-bit and
64-bit).  At the moment, the two power8 systems have no regressions, and the
power7 system is still building.  Assuming the power7 system completes without
regressions, can I check this patch into the trunk?

Assuming the patch applies and causes no regressions, can I check this patch
into GCC 6 and 5 as well.  Since GCC 6/5 do run with reload as the default,
they would likely see the issue.  GCC 7 has switched to LRA, which is more
robust, and doesn't show the problem (unless you use the -mno-lra switch).

[gcc]
2017-03-15  Michael Meissner  

PR target/71294
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Allow a
SPLAT operation on ISA 2.07 64-bit systems that have direct move,
but no MTVSRDD support, by doing MTVSRD and XXPERMDI.

[gcc/testsuite]
2017-03-15  Michael Meissner  

PR target/71294
* g++.dg/pr71294.C: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 246137)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -3067,16 +3067,29 @@ (define_expand "vsx_mergeh_"
 })
 
 ;; V2DF/V2DI splat
-(define_insn "vsx_splat_"
-  [(set (match_operand:VSX_D 0 "vsx_register_operand" "=,,we")
+(define_insn_and_split "vsx_splat_"
+  [(set (match_operand:VSX_D 0 "vsx_register_operand"
+   "=,,we,")
(vec_duplicate:VSX_D
-(match_operand: 1 "splat_input_operand" ",Z,b")))]
+(match_operand: 1 "splat_input_operand"
+   ",Z,b, wr")))]
   "VECTOR_MEM_VSX_P (mode)"
   "@
xxpermdi %x0,%x1,%x1,0
lxvdsx %x0,%y1
-   mtvsrdd %x0,%1,%1"
-  [(set_attr "type" "vecperm,vecload,vecperm")])
+   mtvsrdd %x0,%1,%1
+   #"
+  "&& reload_completed && TARGET_POWERPC64 && !TARGET_P9_VECTOR
+   && int_reg_operand (operands[1], mode)"
+  [(set (match_dup 2)
+   (match_dup 1))
+   (set (match_dup 0)
+   (vec_duplicate:VSX_D (match_dup 2)))]
+{
+  operands[2] = gen_rtx_REG (mode, reg_or_subregno (operands[0]));
+}
+  [(set_attr "type" "vecperm,vecload,vecperm,vecperm")
+   (set_attr "length" "4,4,4,8")])
 
 ;; V4SI splat support
 (define_insn "vsx_splat_v4si"
Index: gcc/testsuite/g++.dg/pr71294.C
===
--- gcc/testsuite/g++.dg/pr71294.C  (revision 0)
+++ gcc/testsuite/g++.dg/pr71294.C  (working copy)
@@ -0,0 +1,60 @@
+// { dg-do compile { target { powerpc64*-*-* && lp64 } } }
+// { dg-require-effective-target powerpc_p8vector_ok } */
+// { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } }
+// { dg-options "-mcpu=power8 -O3 -fstack-protector -mno-lra" }
+
+// PAR target/71294 failed because RELOAD could not figure how create a V2DI
+// vector that auto vectorization created with each element being the same
+// stack address, with stack-protector turned on.
+
+class A;
+template  class B {
+public:
+  _Tp val[m * n];
+};
+class C {
+public:
+  C(A);
+};
+struct D {
+  D();
+  unsigned long [](int);
+  unsigned long *p;
+};
+class A {
+public:
+  template  A(const B<_Tp, m, n> &, bool);
+  int rows, cols;
+  unsigned char *data;
+  unsigned char *datastart;
+  unsigned char *dataend;
+  unsigned char *datalimit;
+  D step;
+};
+template 
+A::A(const B<_Tp, m, n> , bool)
+: rows(m), cols(n) {
+  step[0] = cols * sizeof(_Tp);
+  datastart = data = (unsigned char *)p1.val;
+  datalimit = dataend = datastart + rows * step[0];
+}
+class F {
+public:
+  static void compute(C);
+  template 
+  static void compute(const B<_Tp, m, n> &, B<_Tp, nm, 1> &, B<_Tp, m, nm> &,
+  B<_Tp, n, nm> &);
+};
+D::D() {}
+unsigned long ::operator[](int p1) { return p[p1]; }
+template 
+void F::compute(const B<_Tp, m, n> &, B<_Tp, nm, 1> &, B<_Tp, m, nm> &,
+B<_Tp, n, nm> ) {
+  A a(p4, false);
+  compute(a);
+}
+void fn1() {
+  B

[v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Ville Voutilainen]

Tested on Linux-x64.

2017-03-16  Ville Voutilainen  

Implement LWG 2857, {variant,optional,any}::emplace should
return the constructed value.
* include/std/any (any_cast(any*)): Forward-declare.
(emplace(_Args&&...)): Change the return type and
return a reference to the constructed value.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* include/std/optional (emplace(_Args&&...)): Likewise.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* include/std/variant (emplace<_Tp>(_Args&&...)): Likewise.
(emplace<_Tp>(initializer_list<_Up>, _Args&&...)): Likewise.
(emplace<_Np>(_Args&&...)): Likewise.
(emplace<_Np>(initializer_list<_Up>, _Args&&...)): Likewise.
* testsuite/20_util/any/assign/emplace.cc: Add tests for
checking the return value of emplace.
* testsuite/20_util/any/misc/any_cast_neg.cc: Adjust.
* testsuite/20_util/optional/assignment/6.cc: Add tests for
checking the return value of emplace.
* testsuite/20_util/variant/run.cc: Likewise.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index e807617..fff13d9 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -74,6 +74,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  An @c any object's state is either empty or it stores a contained object
*  of CopyConstructible type.
*/
+  class any;
+  template
+inline _ValueType* any_cast(any* __any) noexcept;
+
   class any
   {
 // Holds either pointer to a heap object or the contained object itself.
@@ -268,18 +272,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 /// Emplace with an object created from @p __args as the contained object.
 template 
-  typename __any_constructible&,
   _Decay<_ValueType>, _Args&&...>::type
   emplace(_Args&&... __args)
   {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));
   }
 
 /// Emplace with an object created from @p __il and @p __args as
 /// the contained object.
 template 
-  typename __any_constructible&,
   _Decay<_ValueType>,
   initializer_list<_Up>,
   _Args&&...>::type
@@ -287,6 +292,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__do_emplace<_Decay<_ValueType>, _Up>
  (__il, std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));
   }
 
 // modifiers
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 5e796ac..3f540ec 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -592,20 +592,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
   template
-   enable_if_t::value>
+   enable_if_t::value, _Tp&>
emplace(_Args&&... __args)
{
  this->_M_reset();
  this->_M_construct(std::forward<_Args>(__args)...);
+ return this->_M_get();
}
 
   template
enable_if_t&,
-_Args&&...>::value>
+_Args&&...>::value, _Tp&>
emplace(initializer_list<_Up> __il, _Args&&... __args)
{
  this->_M_reset();
  this->_M_construct(__il, std::forward<_Args>(__args)...);
+ return this->_M_get();
}
 
   // Destructor is implicit, implemented in _Optional_base.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 46d7b92..58bf8c7 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1007,25 +1007,33 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
-   enable_if_t && __exactly_once<_Tp>>
+   enable_if_t && __exactly_once<_Tp>,
+   _Tp&>
emplace(_Args&&... __args)
{
- this->emplace<__index_of<_Tp>>(std::forward<_Args>(__args)...);
+ auto& ret =
+   this->emplace<__index_of<_Tp>>(std::forward<_Args>(__args)...);
  __glibcxx_assert(holds_alternative<_Tp>(*this));
+ return ret;
}
 
   template
enable_if_t&, _Args...>
-   && __exactly_once<_Tp>>
+   && __exactly_once<_Tp>,
+   _Tp&>
emplace(initializer_list<_Up> __il, _Args&&... __args)
{
- this->emplace<__index_of<_Tp>>(__il, std::forward<_Args>(__args)...);
+ auto& ret =
+   

C++ PATCH for c++/80043, ICE with PMF and -fpermissive

[Jason Merrill]

The issue here was that can_convert_bad doesn't allow this ill-formed
conversion, but instantiate_type does (with -fpermissive).  Fixed by
recognizing that case.  It might be nice to make can_convert_bad
smarter, but that doesn't seem worth the effort.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8c545e7c3e1babf7a97e22f061953c4fa5c7871a
Author: Jason Merrill 
Date:   Wed Mar 15 17:08:42 2017 -0400

PR c++/80043 - ICE with -fpermissive

* typeck.c (convert_for_assignment): Handle instantiate_type
not giving an error.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d24..4e9a1c0 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -8486,7 +8486,12 @@ convert_for_assignment (tree type, tree rhs,
 overloaded function.  Call instantiate_type to get error
 messages.  */
  if (rhstype == unknown_type_node)
-   instantiate_type (type, rhs, tf_warning_or_error);
+   {
+ tree r = instantiate_type (type, rhs, tf_warning_or_error);
+ /* -fpermissive might allow this.  */
+ if (!seen_error ())
+   return r;
+   }
  else if (fndecl)
error ("cannot convert %qT to %qT for argument %qP to %qD",
   rhstype, type, parmnum, fndecl);
diff --git a/gcc/testsuite/g++.dg/parse/ptrmem7.C 
b/gcc/testsuite/g++.dg/parse/ptrmem7.C
new file mode 100644
index 000..37b2689
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/ptrmem7.C
@@ -0,0 +1,16 @@
+// PR c++/80043
+// { dg-options -fpermissive }
+
+struct A
+{
+  template void foo()
+  {
+void (A::* fp)();
+fp = A::foo<0>;// { dg-warning "assuming pointer to member" }
+  }
+};
+
+void bar()
+{
+  A().foo<0>();
+}

[PATCH] Fix tree-prof/pr66295.c

[Segher Boessenkool]

This testcase can only ever be built on x86 (it needs the "avx*"
attributes).  This patch skips the test elsewhere.

Is this okay for trunk?


Segher


2017-03-15  Segher Boessenkool  

gcc/testsuite/
* gcc.dg/tree-prof/pr66295.c: Skip unless on an x86 target.

---
 gcc/testsuite/gcc.dg/tree-prof/pr66295.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c 
b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
index b90ef84..d7d64c4 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
@@ -1,4 +1,5 @@
 /* { dg-require-ifunc "" } */
+/* { dg-skip-if "" { ! { i?86-*-* x86_64-*-* } } } */
 /* { dg-options "-O2" } */
 
 static double bar (double *__restrict, double *__restrict, int)
-- 
1.9.3

New German PO file for 'gcc' (version 7.1-b20170226)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-7.1-b20170226.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Fix location of typeid() (PR c++/80014)

[Jason Merrill]

On Tue, Mar 14, 2017 at 9:05 PM, David Malcolm  wrote:
> OK for trunk now, or should this wait until stage 1?

Stage 1.

> +   cp_token *close_paren = cp_parser_require (parser, CPP_CLOSE_PAREN,
> +  RT_CLOSE_PAREN);
> +   location_t end_loc = close_paren ?
> + close_paren->location : UNKNOWN_LOCATION;
> /* If all went well, simply lookup the type-id.  */
> if (cp_parser_parse_definitely (parser))
>   postfix_expression = get_typeid (type, tf_warning_or_error);
> @@ -6527,13 +6530,23 @@ cp_parser_postfix_expression (cp_parser *parser, bool 
> address_p, bool cast_p,
> /* Compute its typeid.  */
> postfix_expression = build_typeid (expression, 
> tf_warning_or_error);
> /* Look for the `)' token.  */
> -   cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
> +   close_paren
> + = cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
> +   end_loc = close_paren ? close_paren->location : UNKNOWN_LOCATION;

In both cases you're setting end_loc from close_paren, so how about
only computing it once, closer to where it's used?

Jason

Document PR79806 as a non-bug

[Bernd Schmidt]

I suggest we apply the following and close the PR as INVALID (not a 
bug). Ok?



Bernd

Index: pr65693.c
===
--- pr65693.c   (revision 245685)
+++ pr65693.c   (working copy)
@@ -2,6 +2,11 @@
 /* { dg-do compile } */
 /* { dg-options "-O2" } */

+/* This test relies on -O2 to optimize away the division operation
+   that's expanded as part of the alloca.  With -O0, the explicit use
+   of edx causes a compilation failure, which is expected
+   behaviour.  */
+
 int a;

 void

[PATCH] avoid relying on getcwd extensions (PR 80047)

[Martin Sebor]

PR 80047 - fixincludes/fixincl.c: PVS-Studio: Improper Release
of Memory Before Removing Last Reference (CWE-401) points out
that the fixincludes program calls getcwd with the first argument
set to NULL, apparently a Glibc extension, to have the function
allocate the memory to which it then returns a pointer.

The attached patch avoids this and also avoids assuming the
function cannot fail.

This is not a regression so I assume it's not suitable for
GCC 7 but rather for GCC 8 when stage 1 opens.

Martin
PR other/80047 - fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

fixincludes/ChangeLog:

	PR other/80047
	* fixincl.c (process): Avoid relying on getcwd extensions and assuming
	the function will succeed.

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6..6e6eb21 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1353,8 +1353,10 @@ process (void)
   if (access (pz_curr_file, R_OK) != 0)
 {
   int erno = errno;
+  char cwdbuf[MAXPATHLEN];
+  char *cwd = getcwd (cwdbuf, sizeof cwdbuf);
   fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
-   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
+   pz_curr_file, cwd ? cwd : "current working directory",
erno, xstrerror (erno));
   return;
 }

Re: [PATCH] Fix location of sizeof/alignof (PR c++/80016)

[Jason Merrill]

This looks very safe, but not critical enough for stage 4.  So I think
wait for stage 1, and maybe also put it on the branch later.

Jason

On Tue, Mar 14, 2017 at 9:05 PM, David Malcolm  wrote:
> PR c++/80016 reports an issue with bizarre underlined range
> for a complicated expression.
>
> The root cause for the incorrect *starting* location of that range
> is that alignof and sizeof expressions currently have
> start == finish == caret at the opening parenthesis of the
> expression.
>
> This patch fixes this by generating appropriate start and finish
> locations for alignof and sizeof expressions.
>
> Successfully bootstrapped on x86_64-pc-linux-gnu.
>
> OK for trunk now, or should this wait until stage 1?
>
> gcc/cp/ChangeLog:
> PR c++/80016
> * parser.c (cp_parser_unary_expression):  Generate a location
> range for alignof and sizeof expressions.
>
> gcc/testsuite/ChangeLog:
> PR c++/80016
> * g++.dg/plugin/diagnostic-test-expressions-1.C (test_sizeof): New
> test function.
> (test_alignof): New test function.
> ---
>  gcc/cp/parser.c| 19 +--
>  .../g++.dg/plugin/diagnostic-test-expressions-1.C  | 66 
> ++
>  2 files changed, 81 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index aecf9a5..0d9667e 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -7817,12 +7817,11 @@ cp_parser_unary_expression (cp_parser *parser, 
> cp_id_kind * pidk,
>   {
> tree operand, ret;
> enum tree_code op;
> -   location_t first_loc;
> +   location_t start_loc = token->location;
>
> op = keyword == RID_ALIGNOF ? ALIGNOF_EXPR : SIZEOF_EXPR;
> /* Consume the token.  */
> cp_lexer_consume_token (parser->lexer);
> -   first_loc = cp_lexer_peek_token (parser->lexer)->location;
> /* Parse the operand.  */
> operand = cp_parser_sizeof_operand (parser, keyword);
>
> @@ -7858,9 +7857,21 @@ cp_parser_unary_expression (cp_parser *parser, 
> cp_id_kind * pidk,
> TREE_SIDE_EFFECTS (ret) = 0;
> TREE_READONLY (ret) = 1;
>   }
> -   SET_EXPR_LOCATION (ret, first_loc);
>   }
> -   return ret;
> +
> +   /* Construct a location e.g. :
> +  alignof (expr)
> +  ^~
> +  with start == caret at the start of the "alignof"/"sizeof"
> +  token, with the endpoint at the final closing paren.  */
> +   location_t finish_loc
> + = cp_lexer_previous_token (parser->lexer)->location;
> +   location_t compound_loc
> + = make_location (start_loc, start_loc, finish_loc);
> +
> +   cp_expr ret_expr (ret);
> +   ret_expr.set_location (compound_loc);
> +   return ret_expr;
>   }
>
> case RID_NEW:
> diff --git a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C 
> b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
> index 3554086..64eb660 100644
> --- a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
> +++ b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
> @@ -101,6 +101,72 @@ int test_postfix_incdec (int i)
>
>  /* Unary operators.  /
>
> +int test_sizeof (int i)
> +{
> +  __emit_expression_range (0, sizeof(int) + i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, sizeof(int) + i);
> +   ^~~
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, i + sizeof(int)); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, i + sizeof(int));
> +   ~~^
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, sizeof i + i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, sizeof i + i);
> +   ~^~~
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, i + sizeof i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, i + sizeof i);
> +   ~~^~
> +   { dg-end-multiline-output "" } */
> +}
> +
> +int test_alignof (int i)
> +{
> +  __emit_expression_range (0, alignof(int) + i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, alignof(int) + i);
> +   ~^~~
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, i + alignof(int)); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, i 

Re: [PATCH] Remove __gnu_pbds::detail::binary_heap::is_heap (PR libstdc++/62045) [resend]

[Jonathan Wakely]

On 10/03/17 11:54 +, Jonathan Wakely wrote:

On 10/03/17 19:36 +0800, Xi Ruoyao wrote:

Hi,

This was resent to be in both libstdc++ and gcc-patches list.


Thanks.


The ill-formed checking in binary_heap::push_heap has made it
O(n). Remove this checking.


The checking certainly looks redundant, I wouldn't say ill-formed
though (that's a formal term in the C++ standard meaning the code
isn't valid C++).


Since assert_valid also checks if (*this) is a legal heap, we can
remove is_heap and the assertions using it completely.


The patch looks good, and since you're just removing code I don't
think we need a copyright assignment. I'll get this applied to the
active branches, thanks!



I've committed the patch, with a new test to verify that we don't do
too many comparisons on insertion. Thanks again.

Tested powerpc64le-linux, committed to trunk. Backports to follow.


commit e81a1a7754ec90d3ecd3478e397d554d69c81d04
Author: Jonathan Wakely 
Date:   Wed Mar 15 19:01:42 2017 +

PR libstdc++/62045 fix O(N) insertion in pd_ds binary heap

2017-03-15Xi Ruoyao

	PR libstdc++/62045
	* include/ext/pb_ds/qdetail/binary_heap_/binary_heap_.hpp
	(is_heap): Remove.
	(push_heap): Remove the wrong checking using is_heap.
	(make_heap): Remove the assertion using is_heap.
	* include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
	(modify): Ditto.
	(resize_for_insert_if_needed): Add PB_DS_ASSERT_VALID after
	calling make_heap.

2017-03-15  Jonathan Wakely  

	PR libstdc++/62045
	* testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc:
	New test.
	* testsuite/ext/pb_ds/regression/priority_queues.cc: Fix copy
	error in comment.

diff --git a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
index 2755f06..f653a1e 100644
--- a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
+++ b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
@@ -266,20 +266,14 @@ namespace __gnu_pbds
 	const entry_cmp& m_cmp = static_cast(*this);
 	entry_pointer end = m_a_entries + m_size;
 	std::make_heap(m_a_entries, end, m_cmp);
-	_GLIBCXX_DEBUG_ASSERT(is_heap());
   }
 
   void
   push_heap()
   {
-	if (!is_heap())
-	  make_heap();
-	else
-	  {
-	const entry_cmp& m_cmp = static_cast(*this);
-	entry_pointer end = m_a_entries + m_size;
-	std::push_heap(m_a_entries, end, m_cmp);
-	  }
+	const entry_cmp& m_cmp = static_cast(*this);
+	entry_pointer end = m_a_entries + m_size;
+	std::push_heap(m_a_entries, end, m_cmp);
   }
 
   void
@@ -290,15 +284,6 @@ namespace __gnu_pbds
 	std::pop_heap(m_a_entries, end, m_cmp);
   }
 
-  bool
-  is_heap()
-  {
-	const entry_cmp& m_cmp = static_cast(*this);
-	entry_pointer end = m_a_entries + m_size;
-	bool p = std::__is_heap(m_a_entries, end, m_cmp);
-	return p;
-  }
-
 #ifdef _GLIBCXX_DEBUG
   void
   assert_valid(const char*, int) const;
diff --git a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
index f82dd52..d21fe3c 100644
--- a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
+++ b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
@@ -103,7 +103,6 @@ modify(point_iterator it, const_reference r_new_val)
   swap_value_imp(it.m_p_e, r_new_val, s_no_throw_copies_ind);
   fix(it.m_p_e);
   PB_DS_ASSERT_VALID((*this))
-  _GLIBCXX_DEBUG_ASSERT(is_heap());
 }
 
 PB_DS_CLASS_T_DEC
diff --git a/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc b/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc
new file mode 100644
index 000..a61d36f
--- /dev/null
+++ b/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc
@@ -0,0 +1,51 @@
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run }
+
+#include 
+#include 
+
+int count = 0;
+
+struct less
+{
+  bool operator()(int i, int 

Re: [PATCH doc] use "cannot" consistently

[Richard Kenner]

> > The latter references other documents, which advocate for more use of
> > contractions even in formal writing.
> 
> These are legal guides, not obviously relevant in the context
> of technical writing.

Yes and no.  The argument for them is that legal writing is the most formal
of all and has been the slowest to adopt contractions.

Re: [PATCH doc] use "cannot" consistently

[Toon Moene]

On 03/14/2017 09:53 PM, Richard Kenner wrote:


The GCC manual uses "cannot" in most places (280 lines) but there
are a few instances of "can't" (33 lines).

The attached patch replaces the informal "can't" with the former
for consistency.


In my opinion, this is the wrong direction.  Contractions are becoming
more acceptable in even more formal writing and there's even a current
US Supreme Court justice who uses them in her opinions.

I certainly don't think it's worth a change to use "can't" throughout,
but I'm not in favor of eliminating it either.


I think for non-native speakers of English, using the full word is 
easier to read (you can't take my experience as an example, as I was 
exposed to written English 48 years ago).


I think replacing the few instances of can't with cannot is worth the 
clarity.


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: [PATCH] MPX: fix PR middle-end/79753

[Ilya Enkovich]

2017-03-15 20:09 GMT+03:00 Jeff Law :
> On 03/15/2017 04:15 AM, Martin Liška wrote:
>>
>> On 03/14/2017 11:27 PM, Ilya Enkovich wrote:
>>>
>>> 2017-03-10 16:15 GMT+03:00 Martin Liška :

 Hello.

 Currently, __builtin_ia32_bndret is used for all functions that have
 non-void
 return type. I think the right fix is to return bounds just for a
 bounded type.

 Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

 Ready to be installed?
 Martin
>>>
>>>
>>> Hi,
>>>
>>> The fix makes sense and allows you to pass the test but it seems like we
>>> still have the issue in inlining which can result in bndret call with
>>> wrong arg.
>>
>>
>> Hi.
>>
>> The test I added does probably what you mean: a return value of integer
>> is casted
>> to a pointer type. Or?
>>
>>> Do you avoid all such cases by this fix? Can we still have similar
>>> problem
>>> if cast function with integer return type to a function with pointer
>>> return type
>>> and the inline the call (not sure if we can inline such calls)?
>>>
>>> I think this fix still should go to trunk anyway.
>>
>>
>> Good, may I consider this as patch approval?
>
> Yes.  Ilya knows this stuff better than anyone, even if he's not listed as
> an official maintainer.

I'm still in the list :)

Ilya

>
> jeff
>

Re: [PATCH] MPX: fix PR middle-end/79753

[Ilya Enkovich]

2017-03-15 13:15 GMT+03:00 Martin Liška :
> On 03/14/2017 11:27 PM, Ilya Enkovich wrote:
>>
>> 2017-03-10 16:15 GMT+03:00 Martin Liška :
>>>
>>> Hello.
>>>
>>> Currently, __builtin_ia32_bndret is used for all functions that have
>>> non-void
>>> return type. I think the right fix is to return bounds just for a bounded
>>> type.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>> Martin
>>
>>
>> Hi,
>>
>> The fix makes sense and allows you to pass the test but it seems like we
>> still have the issue in inlining which can result in bndret call with
>> wrong arg.
>
>
> Hi.
>
> The test I added does probably what you mean: a return value of integer is
> casted
> to a pointer type. Or?

I suspect problem may still exist when you cast function, not just
returned value.
Inline is supposed to always remove retbnd corresponding to expanded call.
You avoid the problem in the testcase by not producing retbnd call. But in
case of calling a function casted to another function type we might
still hit this
issue in inline. I'll try to make a test.

Thanks,
Ilya

>
>> Do you avoid all such cases by this fix? Can we still have similar problem
>> if cast function with integer return type to a function with pointer
>> return type
>> and the inline the call (not sure if we can inline such calls)?
>>
>> I think this fix still should go to trunk anyway.
>
>
> Good, may I consider this as patch approval?
> Thanks,
> Martin
>
>>
>> Thanks,
>> Ilya
>>
>

Re: [PATCH][GCC][AArch64] Fix incorrect INS in SIMD mov pattern

[James Greenhalgh]

On Wed, Mar 15, 2017 at 04:09:05PM +, Tamar Christina wrote:
> This patch fixes a bug in the SIMD mov pattern where we were doing an
> insert and leaving the rest of the vector in an undetermined state. This
> could cause a bug if something else expects the other lanes to be 0.
>
> Semantically we wanted a mov here and not an insert. This is in line
> with other patterns that use an fmov for the same reason,
> e.g. aarch64_combinez*.
>
> Regression tested on aarch64-none-linux-gnu and no regressions.
>
> OK for trunk?

This isn't technically a regression, but the bug would be subtle enough,
and hard enough to debug that I think we should fix it for GCC 7.

OK for trunk, where else does this need backported to?

Thanks,
James

> gcc/
> 2017-03-15 Tamar Christina; 
>
>   * config/aarch64/aarch64-simd.md (*aarch64_simd_mov)
>   Change ins into fmov.

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[David Malcolm]

On Wed, 2017-03-15 at 14:53 +0100, Martin Liška wrote:
> Hello.
> 
> Following small series exclude some strings from pot files via
> introduction of internal_error_cont function.
> 
> Patch can bootstrap and survives regression tests.
> 
> (Sorry for broken threading because my cover letter was rejected).
> 
> Martin
> 
> marxin (3):
>Introduce internal_error_cont function and use it in cfgrtl.c (PR
>  rtl-optimization/79856).
>Replace error with internal_error_cont in cgraph.c (PR ipa/79857).
>Regenerate gcc.pot.
> 
>   gcc/cfgrtl.c  |   349 +-
>   gcc/cgraph.c  |   139 +-
>   gcc/diagnostic-core.h | 1 +
>   gcc/diagnostic.c  |16 +
>   gcc/diagnostic.def| 1 +
>   gcc/po/exgettext  | 6 +-
>   gcc/po/gcc.pot| 14892 -
> ---
>   7 files changed, 7589 insertions(+), 7815 deletions(-)

[For some reason I only received the 0/3 and 3/3 mail, not 1/3 and 2/3]

In patch 1:

2017-03-13  Martin Liska  

PR rtl-optimization/79856
* cfgrtl.c (try_redirect_by_replacing_jump): Fix GNU coding
style.
(fixup_partition_crossing): Likewise.
(fixup_new_cold_bb): Likewise.
(emit_barrier_after_bb): Likewise.
(force_nonfallthru_and_redirect): Likewise.
(last_bb_in_partition): Likewise.
(rtl_split_edge): Likewise.
(commit_one_edge_insertion): Likewise.
(print_rtl_with_bb): Likewise.
(find_partition_fixes): Use internal_error_cont instead of
error.
(verify_hot_cold_block_grouping): Likewise.
(rtl_verify_edges): Likewise.
(rtl_verify_bb_insns): Likewise.
(rtl_verify_bb_pointers): Likewise.
(rtl_verify_bb_insn_chain): Likewise.
(rtl_verify_fallthru): Likewise.
(purge_dead_edges): Fix GNU coding style.
(fixup_abnormal_edges): Likewise.
(fixup_reorder_chain): Likewise.
(duplicate_insn_chain): Likewise.
* diagnostic-core.h (internal_error_cont): Declare new
function.
* diagnostic.c (diagnostic_action_after_output): Handle
newly added DK_INTERNAL_ERROR.
(internal_error_cont): New function.
* diagnostic.def (DK_INTERNAL_ERROR): New enum value.

...the cfgrtl.c changes are a mixture of hunks that are (mostly)
whitespace fixes, combined with hunks that move over to using
internal_error_cont.

Please can you split this patch up to move the cfgrtl.c coding style
fixes into a separate patch, since this obscures the diagnostic
changes?

Also, as Joseph notes, if a function accepts a string param that isn't
to be translated, don't use "gmsgid" or "msgid" as the param name (just
call it "msg" or somesuch).

Thanks
Dave

Re: [PATCH] Fix PR79908

[Bill Schmidt]

> On Mar 14, 2017, at 9:25 AM, Richard Biener  
> wrote:
> 
> On Tue, Mar 14, 2017 at 3:20 PM, Bill Schmidt
>  wrote:
>> 
>>> On Mar 14, 2017, at 7:50 AM, Bill Schmidt  
>>> wrote:
>>> 
>>> 
 On Mar 14, 2017, at 3:57 AM, Richard Biener  
 wrote:
 
 On Tue, Mar 14, 2017 at 1:04 AM, Bill Schmidt
  wrote:
> 
> Index: gcc/tree-stdarg.c
> ===
> --- gcc/tree-stdarg.c   (revision 246109)
> +++ gcc/tree-stdarg.c   (working copy)
> @@ -1057,7 +1057,7 @@ expand_ifn_va_arg_1 (function *fun)
> types.  */
>  gimplify_assign (lhs, expr, );
>}
> -   else
> +   else if (is_gimple_addressable (expr))
>gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);
 
 This is wrong - we lose side-effects this way and the only reason we 
 gimplify
 is to _not_ lose them.
 
 Better is sth like
 
 Index: gcc/tree-stdarg.c
 ===
 --- gcc/tree-stdarg.c   (revision 246082)
 +++ gcc/tree-stdarg.c   (working copy)
 @@ -1058,7 +1058,7 @@ expand_ifn_va_arg_1 (function *fun)
  gimplify_assign (lhs, expr, );
}
  else
 - gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);
 + gimplify_expr (, , , is_gimple_val, fb_either);
 
  input_location = saved_location;
  pop_gimplify_context (NULL);
>>> 
>>> OK, thanks for the explanation.  Unfortunately this fails bootstrap with a 
>>> failed
>>> assert a little later.  I'll dig further.
>> 
>> Looks like is_gimple_val is too restrictive for MEM_REFs, for which 
>> is_gimple_lvalue
>> passes.  Trying this now:
> 
> Hmm, it should simply gimplify to a load if it's not aggregate.  Can
> you share a testcase
> where it doesn't work?

So taking a step back...

The original problem is that most VA_ARGs get gimplified to a single SSA var,
which always passes the is_gimple_addressable check, so if the LHS has either
been cast away or gone dead, we get a nice lvalue to work with and everyone is
happy.

For a VA_ARG of _Complex type, gimplification instead produces a
COMPLEX_EXPR  where a and b have been reduced to SSA vars.
The is_gimple_addressable check does not pass in this case, so we can't
find the mandated lvalue and ICE in the gimplifier after doing all the work.

I suppose we could paper over this with:

Index: gcc/tree-stdarg.c
===
--- gcc/tree-stdarg.c   (revision 246109)   
+++ gcc/tree-stdarg.c   (working copy)  
@@ -1058,7 +1058,10 @@ expand_ifn_va_arg_1 (function *fun)
gimplify_assign (lhs, expr, );  
  } 
else
- gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);  
+ gimplify_expr (, , , is_gimple_lvalue,  
+fb_lvalue | fb_mayfail);   

...but that is perhaps opening the gate too wide (though we could throw
an error if gimplify_expr fails and expr is not a COMPLEX_EXPR).  The 
COMPLEX_EXPR really is not addressable, but forcing any COMPLEX_EXPR
to a variable in gimplify_expr also seems like overkill.  (All of the tcc_binary
expressions are treated the same; we would fail if somebody asked for an
lvalue of a PLUS_EXPR just the same.)  So offhand I don't see anything
better than the above.

Thoughts?

Thanks,
Bill 

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Jeff Law]

On 03/15/2017 04:12 AM, Martin Liška wrote:

On 03/15/2017 12:58 AM, Ilya Enkovich wrote:

2017-03-13 16:33 GMT+03:00 Martin Liška :

On 03/13/2017 02:07 PM, Richard Biener wrote:

No, that can't happen.  I said that for example for

struct S { ... } s;
foo (s);

pass_by_reference may be true but on gimple you see a struct s as
actual argument.  I'm not sure
what chkp_find_bounds does to 's' in this case.  Like if floats are
passed by reference you might
see a REAL_CST passed to chkp_find_bounds but in reality it will get a
pointer (with bounds
according to the argument slot that was used).


Currently constants have invalid bounds assigned. Thus I guess it
can't cause a trouble
when such constant is used as a pointer. Anyhow, the discrepancy
should be handled better.

Last question related to the patch. May I at least install the part
which adds {COMPLEX,VECTOR}_CSTs
handling as it can happen with -mabi=ms (where formal and actual args
do match)? Or using -mabi=ms + CHKP
does not make sense at all?


Hi,

Originally casted function calls were not taken into account by
instrumentation pass and it
caused such sloppy handling of these casts later. It would be nice to
revise this code.


Hi.

Yep, code revisiting would be needed in this area.



Meanwhile your fix should go to trunk. CHKP instrumentation pass is
supposed to be target
independent and therefore shouldn't rely on any ABI.


As you are MPX maintainer, may I consider that as patch approval?

You can consider it as approval.

jeff

Re: [PATCH] MPX: fix PR middle-end/79753

[Jeff Law]

On 03/15/2017 04:15 AM, Martin Liška wrote:

On 03/14/2017 11:27 PM, Ilya Enkovich wrote:

2017-03-10 16:15 GMT+03:00 Martin Liška :

Hello.

Currently, __builtin_ia32_bndret is used for all functions that have
non-void
return type. I think the right fix is to return bounds just for a
bounded type.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Martin


Hi,

The fix makes sense and allows you to pass the test but it seems like we
still have the issue in inlining which can result in bndret call with
wrong arg.


Hi.

The test I added does probably what you mean: a return value of integer
is casted
to a pointer type. Or?


Do you avoid all such cases by this fix? Can we still have similar
problem
if cast function with integer return type to a function with pointer
return type
and the inline the call (not sure if we can inline such calls)?

I think this fix still should go to trunk anyway.


Good, may I consider this as patch approval?
Yes.  Ilya knows this stuff better than anyone, even if he's not listed 
as an official maintainer.


jeff

Re: Combiner fix for PR79910

[Jeff Law]

On 03/15/2017 09:00 AM, Bernd Schmidt wrote:

On 03/15/2017 12:09 AM, Bernd Schmidt wrote:

 I'll retest with your
suggestion and with the bitmap creation conditional on i1 being nonnull.


Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok?

Yea, not surprised you needed the bitmap_empty_p.

OK with or without the debug counter -- your decide on whether or not to 
include it.


jeff

Re: [PATCH 3/3] Regenerate gcc.pot.

[Joseph Myers]

On Wed, 15 Mar 2017, Martin Liška wrote:

> gcc/po/ChangeLog:
> 
> 2017-03-15  Martin Liska  
> 
>   * exgettext: Exclude internal_error_cont from location.

If you don't want a function's arguments to be extracted for translation, 
you should not special-case it in exgettext.  Instead:

* Ensure the relevant arguments do not have names ending "msgid", so that 
the arguments are not extracted to gcc.pot.

* Ensure that the arguments end up going to diagnostic_set_info_translated 
without passing through the _() call in diagnostic_set_info, so no attempt 
is made to translate at runtime.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH doc] use "cannot" consistently

[Martin Sebor]

On 03/15/2017 09:40 AM, Martin Sebor wrote:

On 03/15/2017 05:00 AM, Richard Kenner wrote:

First, I agree that the less formal language is becoming more
acceptable.  Some style guides explicitly allow contractions,
but others advise against them.  The technical specifications
that significant parts of GCC aim to conform to, and those I
happen  to work with the most closely (the C, C++, and POSIX
standards), avoid them.  The IEEE Editorial Style Manual
recommends against using them.  The author of Engineer's Guide
to Technical Writing, Kenneth Budinski, equates them with slang.


How old are those documents?  More recently, see


They're all the latest versions (C++ 2011, C++ 2017, and the IEEE
Editorial Style Manual is the 2016 update).

But to get a more representative sample I've surveyed some other
references I have sitting on my hard drive.  I found none that
uses contractions:

  ARM Compiler Toolchain 4.1 Reference (2011)
  Clang 5,0 Compiler User’s Manual(*) (2017)
  DWARF Debugging Information Format Version 5 (2017)
  HP aCC 6.20 C Programmer's Guide(**)(2008)
  IBM Power ISA Version 3.0 (2015)
  IBM XL C/C++ for Linux, V13.1 Compiler Reference (2014)
  Intel C++ Compiler 17.0 Developer Guide and Reference (2016)
  Intel 64 and IA-32 Architectures Software Developer’s Manual (2011)
  MIPS64 Architecture for Programmers (2010)
  Oracle Developer Studio 12.5 C/C++ Users Guide (2016)

  [*] Except for a few instances of don't.
  [**] "Can't" used in comments in coding examples.



http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm

https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/

The latter references other documents, which advocate for more use of
contractions even in formal writing.


These are legal guides, obviously not relevant in the context
of technical writing.


Sorry, I meant "not obviously relevant."




I personally don't feel too strongly about it, but the change
seems like an opportunity to improve not just the style of
the manual but also increase its consistency.  I could see
one being indifferent to such changes but I have trouble
understanding how they could be viewed as the wrong direction.
What is your rationale against it and what would you consider
the right direction for the manual?


I think it's the wrong direction because I'd be in favor of gradually
*introducing* contractions into to the manual instead of a change that
eliminates them.  I wouldn't be against a change that went in the other
direction (used contractions consistently), but it would be good a large
change, so I'm not advocating for doing that, but just instead using
contractions in all new material and when modifying old material for
other reasons.


My disagreement aside, I should have thanked you for clarifying
your view.  (Thank you.)



Interesting.  I don't share that view and clearly neither do
writers of any of the technical specifications I listed above
but I will go along with whatever the documentation maintainers
think is appropriate or preferable for GCC.

Martin

[PATCH][GCC][AArch64] Fix incorrect INS in SIMD mov pattern

[Tamar Christina]

Hi All, 


This patch fixes a bug in the SIMD mov pattern where we were doing an
insert and leaving the rest of the vector in an undetermined state. This
could cause a bug if something else expects the other lanes to be 0.

Semantically we wanted a mov here and not an insert. This is in line
with other patterns that use an fmov for the same reason,
e.g. aarch64_combinez*. 

Regression tested on aarch64-none-linux-gnu and no regressions.

OK for trunk?

Thanks,
Tamar


gcc/
2017-03-15  Tamar Christina  

* config/aarch64/aarch64-simd.md (*aarch64_simd_mov)
Change ins into fmov.diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index b61f79a09462b8cecca7dd2cc4ac0eb4be2dbc79..e8ec9489d111a2c9227d418386bbcf54c81d14ec 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -107,7 +107,7 @@
  case 1: return "str\\t%d1, %0";
  case 2: return "orr\t%0., %1., %1.";
  case 3: return "umov\t%0, %1.d[0]";
- case 4: return "ins\t%0.d[0], %1";
+ case 4: return "fmov\t%d0, %1";
  case 5: return "mov\t%0, %1";
  case 6:
 	return aarch64_output_simd_mov_immediate (operands[1],
@@ -116,8 +116,8 @@
  }
 }
   [(set_attr "type" "neon_load1_1reg, neon_store1_1reg,\
- neon_logic, neon_to_gp, neon_from_gp,\
- mov_reg, neon_move")]
+		 neon_logic, neon_to_gp, f_mcr,\
+		 mov_reg, neon_move")]
 )
 
 (define_insn "*aarch64_simd_mov"

[PATCH][GCC][AArch64] Fix subreg bug in scalar copysign

[Tamar Christina]

Hi All, 

This fixes a bug in the scalar version of copysign where due to a subreg
were generating less than efficient code.

This patch replaces

  return x * __builtin_copysignf (150.0f, y);

which used to generate

adrpx1, .LC1
mov x0, 2147483648
ins v3.d[0], x0
ldr s2, [x1, #:lo12:.LC1]
bsl v3.8b, v1.8b, v2.8b
fmuls0, s0, s3
ret

.LC1:
.word   1125515264

with
mov x0, 1125515264
moviv2.2s, 0x80, lsl 24
fmovd3, x0
bit v3.8b, v1.8b, v2.8b
fmuls0, s0, s3
ret

removing the incorrect ins.

Regression tested on aarch64-none-linux-gnu and no regressions.

OK for trunk?

Thanks,
Tamar

gcc/
2017-03-15  Tamar Christina  

* config/aarch64/aarch64.md
(copysignsf3): Fix mask generation.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 5adc5edb8dde9c30450b04932a37c41f84cc5ed1..435c8f50c0e521b3057c26a482315c5a82574711 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -5030,14 +5030,16 @@
(match_operand:SF 2 "register_operand")]
   "TARGET_FLOAT && TARGET_SIMD"
 {
-  rtx mask = gen_reg_rtx (DImode);
+  rtx v_bitmask = gen_reg_rtx (V2SImode);
 
   /* Juggle modes to get us in to a vector mode for BSL.  */
-  rtx op1 = lowpart_subreg (V2SFmode, operands[1], SFmode);
+  rtx op1 = lowpart_subreg (DImode, operands[1], SFmode);
   rtx op2 = lowpart_subreg (V2SFmode, operands[2], SFmode);
   rtx tmp = gen_reg_rtx (V2SFmode);
-  emit_move_insn (mask, GEN_INT (HOST_WIDE_INT_1U << 31));
-  emit_insn (gen_aarch64_simd_bslv2sf (tmp, mask, op2, op1));
+  emit_move_insn (v_bitmask,
+		  aarch64_simd_gen_const_vector_dup (V2SImode,
+		 HOST_WIDE_INT_M1U << 31));
+  emit_insn (gen_aarch64_simd_bslv2sf (tmp, v_bitmask, op2, op1));
   emit_move_insn (operands[0], lowpart_subreg (SFmode, tmp, V2SFmode));
   DONE;
 }

RE: [PATCH,testsuite] Skip gcc.dg/pic-2.c and gcc.dg/pie-2.c for MIPS.

[Matthew Fortune]

Toma Tabacu  writes:
> The gcc.dg/pic-2.c and gcc.dg/pie-2.c tests are failing for MIPS targets
> because __PIC__ is always set to 1 for MIPS.
> 
> This patch makes the testsuite skip those two tests for all MIPS
> targets.
> 
> Tested with mips-mti-elf and mips-mti-linux-gnu.
> 
> Should I have fixed this in target-supports.exp instead ?
> I was worried that doing so would complicate the fpic and pie effective
> target checks too much.

I think the skip is OK here. I'd like to get Catherine's opinion on
this though too. I don't think we should change the definition of __PIC__
for -fPIC on MIPS as multi-got solves 'most' issues. If we start trying to
figure out what __PIC__ should mean on MIPS then we will get into a big
mess with -mxgot as that is arguably __PIC__==2 but I expect there will be
several differing opinions.

Thanks,
Matthew

> 
> Regards,
> Toma
> 
> gcc/testsuite/
> 
>   * gcc.dg/pic-2.c: Skip for MIPS.
>   * gcc.dg/pie-2.c: Skip for MIPS.
> 
> diff --git a/gcc/testsuite/gcc.dg/pic-2.c b/gcc/testsuite/gcc.dg/pic-2.c
> index 59ce8e2..bccec13 100644
> --- a/gcc/testsuite/gcc.dg/pic-2.c
> +++ b/gcc/testsuite/gcc.dg/pic-2.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target fpic } */
>  /* { dg-options "-fPIC" } */
> +/* { dg-skip-if "__PIC__ is always 1 for MIPS" { mips*-*-* } } */
> 
>  #if __PIC__ != 2
>  # error __PIC__ is not 2!
> diff --git a/gcc/testsuite/gcc.dg/pie-2.c b/gcc/testsuite/gcc.dg/pie-2.c
> index 7bdc4ac..1838745 100644
> --- a/gcc/testsuite/gcc.dg/pie-2.c
> +++ b/gcc/testsuite/gcc.dg/pie-2.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-options "-fPIE" } */
>  /* { dg-require-effective-target pie } */
> +/* { dg-skip-if "__PIC__ is always 1 for MIPS" { mips*-*-* } } */
> 
>  #if __PIC__ != 2
>  # error __PIC__ is not 2!

Re: [PATCH doc] use "cannot" consistently

[Martin Sebor]

On 03/15/2017 05:00 AM, Richard Kenner wrote:

First, I agree that the less formal language is becoming more
acceptable.  Some style guides explicitly allow contractions,
but others advise against them.  The technical specifications
that significant parts of GCC aim to conform to, and those I
happen  to work with the most closely (the C, C++, and POSIX
standards), avoid them.  The IEEE Editorial Style Manual
recommends against using them.  The author of Engineer's Guide
to Technical Writing, Kenneth Budinski, equates them with slang.


How old are those documents?  More recently, see


They're all the latest versions (C++ 2011, C++ 2017, and the IEEE
Editorial Style Manual is the 2016 update).

But to get a more representative sample I've surveyed some other
references I have sitting on my hard drive.  I found none that
uses contractions:

  ARM Compiler Toolchain 4.1 Reference (2011)
  Clang 5,0 Compiler User’s Manual(*) (2017)
  DWARF Debugging Information Format Version 5 (2017)
  HP aCC 6.20 C Programmer's Guide(**)(2008)
  IBM Power ISA Version 3.0 (2015)
  IBM XL C/C++ for Linux, V13.1 Compiler Reference (2014)
  Intel C++ Compiler 17.0 Developer Guide and Reference (2016)
  Intel 64 and IA-32 Architectures Software Developer’s Manual (2011)
  MIPS64 Architecture for Programmers (2010)
  Oracle Developer Studio 12.5 C/C++ Users Guide (2016)

  [*] Except for a few instances of don't.
  [**] "Can't" used in comments in coding examples.


http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm
https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/

The latter references other documents, which advocate for more use of
contractions even in formal writing.


These are legal guides, obviously not relevant in the context
of technical writing.


I personally don't feel too strongly about it, but the change
seems like an opportunity to improve not just the style of
the manual but also increase its consistency.  I could see
one being indifferent to such changes but I have trouble
understanding how they could be viewed as the wrong direction.
What is your rationale against it and what would you consider
the right direction for the manual?


I think it's the wrong direction because I'd be in favor of gradually
*introducing* contractions into to the manual instead of a change that
eliminates them.  I wouldn't be against a change that went in the other
direction (used contractions consistently), but it would be good a large
change, so I'm not advocating for doing that, but just instead using
contractions in all new material and when modifying old material for
other reasons.


Interesting.  I don't share that view and clearly neither do
writers of any of the technical specifications I listed above
but I will go along with whatever the documentation maintainers
think is appropriate or preferable for GCC.

Martin

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

[Jiong Wang]

On 15/03/17 15:34, Rainer Orth wrote:

Hi Jiong,


Subject: [PATCH] testsuite, 79356

As stated in the PR (and elsewhere), this test now passes on aarch64,
ia64, mips, powerpc, sparc, and s390x.  This patch disables the xfails
for those targets.


gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips,
powerpc, sparc, or s390x.


It's passing on ARM as well.

I will commit the following patch which add arm*-*-* to the "Don't xfail".

gcc/testsuite/
 PR testsuite/79356
 * gcc.dg/attr-alloc_size-11.c: Don't xfail on arm.

please keep the lists sorted alphabetically.


Thanks, noticed that just during committing, the committed one has been 
corrected.

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c?r1=246167=246166=246167

[wwwdocs] Add more libstdc++ changes to /gcc-7/changes.html

[Jonathan Wakely]

Some recent changes.
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.71
diff -u -r1.71 changes.html
--- htdocs/gcc-7/changes.html	14 Mar 2017 19:42:38 -	1.71
+++ htdocs/gcc-7/changes.html	15 Mar 2017 15:32:04 -
@@ -623,6 +623,12 @@
 
 Runtime Library (libstdc++)
 
+  
+The type of exception thrown by iostreams,
+std::ios_base::failure, now uses the
+https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html;>cxx11
+ABI.
+  
   Experimental support for C++17, including the following new features:
   
 
@@ -633,8 +639,8 @@
   and std::variant;
 
 
-  std::invoke, std::is_callable,
-  and std::is_nothrow_callable;
+  std::invoke, std::is_invocable,
+  std::is_nothrow_invocable, and invoke_result;
 
 
   std::is_swappable,
@@ -649,6 +655,7 @@
   std::conjunction, std::disjunction,
   and std::negation;
 
+Variable templates for type traits;
 Mathematical Special Functions;
 
   std::chrono::floor, std::chrono::ceil,
@@ -658,8 +665,12 @@
   std::clamp, std::gcd, std::lcm,
   3-dimensional std::hypot;
 
-std::shared_mutex;
-std::default_searcher,
+
+  std::scoped_lock, std::shared_mutex,
+  std::atomicT::is_always_lock_free;
+
+
+  std::sample, std::default_searcher,
   std::boyer_moore_searcher and
   std::boyer_moore_horspool_searcher;
 
@@ -675,6 +686,7 @@
   std::enable_shared_from_thisT::weak_from_this(),
   and std::owner_lessvoid;
 
+std::byte;
 std::as_const, std::not_fn,
   std::has_unique_object_representations,
   constexpr std::addressof.

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

[Rainer Orth]

Hi Jiong,

>> Subject: [PATCH] testsuite, 79356
>>
>> As stated in the PR (and elsewhere), this test now passes on aarch64,
>> ia64, mips, powerpc, sparc, and s390x.  This patch disables the xfails
>> for those targets.
>>
>>
>> gcc/testsuite/
>>  PR testsuite/79356
>>  * gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips,
>>  powerpc, sparc, or s390x.
>>
> It's passing on ARM as well.
>
> I will commit the following patch which add arm*-*-* to the "Don't xfail".
>
> gcc/testsuite/
> PR testsuite/79356
> * gcc.dg/attr-alloc_size-11.c: Don't xfail on arm.

please keep the lists sorted alphabetically.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RE: [PATCH] Fix MIPS-specific ICE in gcc.dg/pr77834.c (PR rtl-optimization/79150).

[Matthew Fortune]

Hi Catherine,

What is your opinion on this patch? I am OK with the temporary
workaround on the basis that the additional nop is successfully
eliminated so there is no code size increase. Also, I am happy
enough that the CFG is fixed very soon after the block move is
expanded so the 'bad' basic block is fixed almost immediately
anyway making the offending check potentially unnecessary in
the first place.

Thanks,
Matthew

> -Original Message-
> From: Toma Tabacu
> Sent: 07 March 2017 11:44
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune; Segher Boessenkool (seg...@kernel.crashing.org)
> Subject: [PATCH] Fix MIPS-specific ICE in gcc.dg/pr77834.c (PR rtl-
> optimization/79150).
> 
> Hi,
> 
> This ICE is caused by "gcc_assert (!JUMP_P (last))" in
> commit_one_edge_insertion (gcc/cfgrtl.c):
> 
>   if (returnjump_p (last))
> {
>   /* ??? Remove all outgoing edges from BB and add one for EXIT.
>This is not currently a problem because this only happens
>for the (single) epilogue, which already has a fallthru edge
>to EXIT.  */
> 
>   e = single_succ_edge (bb);
>   gcc_assert (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
> && single_succ_p (bb) && (e->flags & EDGE_FALLTHRU));
> 
>   e->flags &= ~EDGE_FALLTHRU;
>   emit_barrier_after (last);
> 
>   if (before)
>   delete_insn (before);
> }
>   else
> gcc_assert (!JUMP_P (last));
> 
> The assert is triggered because we're removing an edge which ends on a
> conditional jump, which is part of a loop.
> 
> The reason for the existence of this loop is the size of the vector used
> in gcc.dg/pr77834.c.
> When compiling code which uses vectors for MIPS, a looping memcpy is
> generated if the vectors are big enough (>32 bytes for MIPS32 or >64
> bytes for MIPS64).
> This takes place in mips_expand_block_move (gcc/config/mips.c).
> 
> In our case, a looping memcpy gets generated for a partition copy which
> is inserted on an edge (in insert_partition_copy_on_edge, gcc/tree-
> outof-ssa.c).
> This happens during PHI node elimination, which is done by eliminate_phi
> (gcc/tree-outof-ssa.c), as a part of expand_phi_nodes, which is called
> by the expand pass (gcc/cfgexpand.c).
> 
> My original fix was to update the CFG by calling
> find_many_sub_basic_blocks with an all-one block bitmap (which also
> happens in cfgexpand.c, after edge
> removal) whenever an edge contains an insn which satisfies
> control_flow_insn_p.
> However, Segher Boessenkool said that this would be too risky for stage
> 4 and suggested inserting a NOP after the conditional jump in order to
> fool the assert. This assumes that it is safe to delay the CFG update
> for this particular case.
> 
> This patch changes mips_block_move_loop to emit a NOP after the
> conditional jump, if the jump is the last insn of the loop. This
> prevents "gcc_assert (!JUMP_P (last))" from triggering.
> 
> The NOP will never make it into the final assembly code because it is
> removed during the cse1 pass through DCE for -O1, -O2, and -O3, and it's
> not even emitted for -O0 and -Os because looping memcpy's are not
> generated for those optimization levels, as can be seen in
> mips_expand_block_move from mips.c:
> 
>   if (INTVAL (length) <= MIPS_MAX_MOVE_BYTES_STRAIGHT)
>   {
> mips_block_move_straight (dest, src, INTVAL (length));
> return true;
>   }
>   else if (optimize)
>   {
> mips_block_move_loop (dest, src, INTVAL (length),
>   MIPS_MAX_MOVE_BYTES_PER_LOOP_ITER);
> return true;
>   }
> 
> Tested with mips-mti-elf.
> 
> Regards,
> Toma Tabacu
> 
> gcc/
> 
>   * config/mips/mips.c (mips_block_move_loop): Emit a NOP after the
>   conditional jump, if the jump is the last insn of the loop.
> 
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
> 4e13fbe..43e719f 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -8098,6 +8098,9 @@ mips_block_move_loop (rtx dest, rtx src,
> HOST_WIDE_INT length,
>/* Mop up any left-over bytes.  */
>if (leftover)
>  mips_block_move_straight (dest, src, leftover);
> +  else
> +/* Temporary fix for PR79150.  */
> +emit_insn (gen_nop ());
>  }
> 
>  /* Expand a movmemsi instruction, which copies LENGTH bytes from

[PATCH,testsuite] Skip gcc.dg/pic-2.c and gcc.dg/pie-2.c for MIPS.

[Toma Tabacu]

Hi,

The gcc.dg/pic-2.c and gcc.dg/pie-2.c tests are failing for MIPS targets
because __PIC__ is always set to 1 for MIPS.

This patch makes the testsuite skip those two tests for all MIPS targets.

Tested with mips-mti-elf and mips-mti-linux-gnu.

Should I have fixed this in target-supports.exp instead ?
I was worried that doing so would complicate the fpic and pie effective target
checks too much.

Regards,
Toma

gcc/testsuite/

* gcc.dg/pic-2.c: Skip for MIPS.
* gcc.dg/pie-2.c: Skip for MIPS.

diff --git a/gcc/testsuite/gcc.dg/pic-2.c b/gcc/testsuite/gcc.dg/pic-2.c
index 59ce8e2..bccec13 100644
--- a/gcc/testsuite/gcc.dg/pic-2.c
+++ b/gcc/testsuite/gcc.dg/pic-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target fpic } */
 /* { dg-options "-fPIC" } */
+/* { dg-skip-if "__PIC__ is always 1 for MIPS" { mips*-*-* } } */
 
 #if __PIC__ != 2
 # error __PIC__ is not 2!
diff --git a/gcc/testsuite/gcc.dg/pie-2.c b/gcc/testsuite/gcc.dg/pie-2.c
index 7bdc4ac..1838745 100644
--- a/gcc/testsuite/gcc.dg/pie-2.c
+++ b/gcc/testsuite/gcc.dg/pie-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-fPIE" } */
 /* { dg-require-effective-target pie } */
+/* { dg-skip-if "__PIC__ is always 1 for MIPS" { mips*-*-* } } */
 
 #if __PIC__ != 2
 # error __PIC__ is not 2!

[PATCH] Fix typo in config.h.in comment

[Jonathan Wakely]

I'm committing this patch to fix a typo in /* Define if ... */ comment
that ends up in config.h

This was submitted as a pull request against the unofficial github
mirror: https://github.com/gcc-mirror/gcc/pull/10

* acinclude.m4 (GLIBCXX_CHECK_S_ISREG_OR_S_IFREG): Fix typo in
comment.
* config.h.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.

Tested powerpc64le-linux. Committed to trunk.

commit 8a20233e72a12c97b192ed38440371beaf9a5b76
Author: Jonathan Wakely 
Date:   Wed Mar 15 11:37:53 2017 +

Fix typo in config.h.in comment

* acinclude.m4 (GLIBCXX_CHECK_S_ISREG_OR_S_IFREG): Fix typo in
comment.
* config.h.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 5998fe6..8cb525b 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -397,7 +397,7 @@ AC_DEFUN([GLIBCXX_CHECK_S_ISREG_OR_S_IFREG], [
   res=no
   if test $glibcxx_cv_S_ISREG = yes; then
 AC_DEFINE(HAVE_S_ISREG, 1,
- [Define if S_IFREG is available in .])
+ [Define if S_ISREG is available in .])
 res=S_ISREG
   elif test $glibcxx_cv_S_IFREG = yes; then
 AC_DEFINE(HAVE_S_IFREG, 1,

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

[Jiong Wang]

On 10/03/17 15:26, Segher Boessenkool wrote:

On Fri, Mar 10, 2017 at 01:57:31PM +0100, Rainer Orth wrote:

I just noticed that nothing has happened at all in a month, so anything
is better than the tests XPASSing on a number of targets.

So the patch is ok for mainline with sparc*-*-* added to the target
lists and a reference to PR testsuite/79356 in the comment.

I'd still be very grateful if Martin could have a look what's really
going on here, though.

Same here.

Committed as:


Subject: [PATCH] testsuite, 79356

As stated in the PR (and elsewhere), this test now passes on aarch64,
ia64, mips, powerpc, sparc, and s390x.  This patch disables the xfails
for those targets.


gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips,
powerpc, sparc, or s390x.


It's passing on ARM as well.

I will commit the following patch which add arm*-*-* to the "Don't xfail".

gcc/testsuite/
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on arm.


diff --git a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
index ccf2c2196c065b3387a91cc764dad3fcc1b4e3ee..3c1867bfb4e1cb762308dc6ac03afc7dc01cc075 100644
--- a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
+++ b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
@@ -47,8 +47,8 @@ typedef __SIZE_TYPE__size_t;
 
 /* The following tests fail because of missing range information.  The xfail
exclusions are PR79356.  */
-TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX);   /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for signed char" { xfail { ! { aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
-TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for short" { xfail { ! { aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
+TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX);   /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for signed char" { xfail { ! { arm*-*-* aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
+TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for short" { xfail { ! { arm*-*-* aarch64*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
 TEST (int, INT_MIN + 2, ALLOC_MAX);/* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
 TEST (int, -3, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
 TEST (int, -2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */

[PATCH] rs6000: Do not xfail nint_2.f90 on Linux systems

[Segher Boessenkool]

It was XFAILed because there was a bug in glibc, but that bug was fixed
nine years ago.  Nowadays everyone uses a version of glibc with the bug
fixed, so we should no longer XFAIL the test.

This fixes it.  Testing on powerpc64-linux {-m32,-m64}, will commit if
that succeeds.


Segher


2017-03-15  Segher Boessenkool  

gcc/testsuite/
PR fortran/33271
* gfortran.dg/nint_2.f90: Do not xfail powerpc*-*-linux*.

---
 gcc/testsuite/gfortran.dg/nint_2.f90 | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/nint_2.f90 
b/gcc/testsuite/gfortran.dg/nint_2.f90
index 0727136..be195e7 100644
--- a/gcc/testsuite/gfortran.dg/nint_2.f90
+++ b/gcc/testsuite/gfortran.dg/nint_2.f90
@@ -4,8 +4,7 @@
 ! http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html
 !
 ! { dg-do run }
-! { dg-xfail-run-if "PR 33271, math library bug" { powerpc-ibm-aix* 
powerpc-*-linux* powerpc64-*-linux* *-*-mingw* } { "-O0" } { "" } }
-! Note that this doesn't fail on powerpc64le-*-linux*.
+! { dg-xfail-run-if "PR 33271, math library bug" { powerpc-ibm-aix* *-*-mingw* 
} { "-O0" } { "" } }
   real(kind=8) :: a
   integer(kind=8) :: i1, i2
   real :: b
-- 
1.9.3

Re: [PATCH][AArch64] Implement ALU_BRANCH fusion

[Wilco Dijkstra]

Hi,

I think the patch isn't quite complete yet. You will also need changes in
generic code. Currently sched_macro_fuse_insns() does:

  if (any_condjump_p (insn))
{
  unsigned int condreg1, condreg2;
  rtx cc_reg_1;
  targetm.fixed_condition_code_regs (, );
  cc_reg_1 = gen_rtx_REG (CCmode, condreg1);
  prev = prev_nonnote_nondebug_insn (insn);
  if (!reg_referenced_p (cc_reg_1, PATTERN (insn))
  || !prev
  || !modified_in_p (cc_reg_1, prev))
return;
}

Ie. it explicitly looks for a flag-setting ALU instruction whose condition is
used by a conditional branch, so none of the cases in your patch can match.

Note this code also excludes all CBZ type branches as fusion candidates,
is that intended too?

Wilco

Re: Combiner fix for PR79910

[Bernd Schmidt]

On 03/15/2017 04:00 PM, Bernd Schmidt wrote:

On 03/15/2017 12:09 AM, Bernd Schmidt wrote:

 I'll retest with your
suggestion and with the bitmap creation conditional on i1 being nonnull.


Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok?


Oops, that one also has dbg_cnt stuff in it which I was going to remove. 
If you want to approve that along with the rest, the following bit is 
also needed:


Index: gcc/dbgcnt.def
===
--- gcc/dbgcnt.def  (revision 245685)
+++ gcc/dbgcnt.def  (working copy)
@@ -145,6 +145,7 @@ DEBUG_COUNTER (asan_use_after_scope)
 DEBUG_COUNTER (auto_inc_dec)
 DEBUG_COUNTER (ccp)
 DEBUG_COUNTER (cfg_cleanup)
+DEBUG_COUNTER (combine)
 DEBUG_COUNTER (cprop)
 DEBUG_COUNTER (cse2_move2add)
 DEBUG_COUNTER (dce)


Bernd

Re: Combiner fix for PR79910

[Bernd Schmidt]

On 03/15/2017 12:09 AM, Bernd Schmidt wrote:

 I'll retest with your
suggestion and with the bitmap creation conditional on i1 being nonnull.


Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok?


Bernd

Index: gcc/combine.c
===
--- gcc/combine.c	(revision 245685)
+++ gcc/combine.c	(working copy)
@@ -104,6 +104,7 @@ along with GCC; see the file COPYING3.
 #include "valtrack.h"
 #include "rtl-iter.h"
 #include "print-rtl.h"
+#include "dbgcnt.h"
 
 /* Number of attempts to combine instructions in this function.  */
 
@@ -2559,6 +2560,57 @@ can_split_parallel_of_n_reg_sets (rtx_in
   return true;
 }
 
+/* Set up a set of registers used in an insn.  Called through note_uses,
+   arguments as described for that function.  */
+
+static void
+record_used_regs (rtx *xptr, void *data)
+{
+  bitmap set = (bitmap)data;
+  int i, j;
+  enum rtx_code code;
+  const char *fmt;
+  rtx x = *xptr;
+
+  /* repeat is used to turn tail-recursion into iteration since GCC
+ can't do it when there's no return value.  */
+ repeat:
+  if (x == 0)
+return;
+
+  code = GET_CODE (x);
+  if (REG_P (x))
+{
+  unsigned regno = REGNO (x);
+  unsigned end_regno = END_REGNO (x);
+  while (regno < end_regno)
+	bitmap_set_bit (set, regno++);
+  return;
+}
+
+  /* Recursively scan the operands of this expression.  */
+
+  for (i = GET_RTX_LENGTH (code) - 1, fmt = GET_RTX_FORMAT (code); i >= 0; i--)
+{
+  if (fmt[i] == 'e')
+	{
+	  /* If we are about to do the last recursive call
+	 needed at this level, change it into iteration.
+	 This function is called enough to be worth it.  */
+	  if (i == 0)
+	{
+	  x = XEXP (x, 0);
+	  goto repeat;
+	}
+
+	  record_used_regs ( (x, i), data);
+	}
+  else if (fmt[i] == 'E')
+	for (j = 0; j < XVECLEN (x, i); j++)
+	  record_used_regs ( (x, i, j), data);
+}
+}
+
 /* Try to combine the insns I0, I1 and I2 into I3.
Here I0, I1 and I2 appear earlier than I3.
I0 and I1 can be zero; then we combine just I2 into I3, or I1 and I2 into
@@ -2742,6 +2794,27 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
 
   added_links_insn = 0;
 
+  /* For combinations that may result in two insns, we have to gather
+ some extra information about registers used, so that we can
+ update all relevant LOG_LINKS later.  */
+  auto_bitmap i2_regset, i3_regset, links_regset;
+  if (i1)
+{
+  note_uses ( (i2), record_used_regs, (bitmap)i2_regset);
+  note_uses ( (i3), record_used_regs, (bitmap)i3_regset);
+  insn_link *ll;
+  FOR_EACH_LOG_LINK (ll, i3)
+	bitmap_set_bit (links_regset, ll->regno);
+  FOR_EACH_LOG_LINK (ll, i2)
+	bitmap_set_bit (links_regset, ll->regno);
+  if (i1)
+	FOR_EACH_LOG_LINK (ll, i1)
+	  bitmap_set_bit (links_regset, ll->regno);
+  if (i0)
+	FOR_EACH_LOG_LINK (ll, i0)
+	  bitmap_set_bit (links_regset, ll->regno);
+}
+
   /* First check for one important special case that the code below will
  not handle.  Namely, the case where I1 is zero, I2 is a PARALLEL
  and I3 is a SET whose SET_SRC is a SET_DEST in I2.  In that case,
@@ -4004,6 +4077,12 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
 	}
 }
 
+  if (!dbg_cnt (combine))
+{
+  undo_all ();
+  return 0;
+}
+
   /* If it still isn't recognized, fail and change things back the way they
  were.  */
   if ((insn_code_number < 0
@@ -4051,6 +4130,33 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   return 0;
 }
 
+  auto_bitmap new_regs_in_i2;
+  if (newi2pat)
+{
+  /* We need to discover situations where we introduce a use of a
+	 register into I2, where none of the existing LOG_LINKS contain
+	 a reference to it.  This can happen if previously I3 referenced
+	 the reg, and there is an additional use between I2 and I3.  We
+	 must remove the LOG_LINKS entry from that additional use and
+	 distribute it along with our own ones.  */
+	note_uses (, record_used_regs, (bitmap)new_regs_in_i2);
+	bitmap_and_compl_into (new_regs_in_i2, i2_regset);
+	bitmap_and_compl_into (new_regs_in_i2, links_regset);
+
+	/* Here, we first look for situations where a hard register use
+	   moved, and just give up.  This should happen approximately
+	   never, and it's not worth it to deal with possibilities like
+	   multi-word registers.  Later, when fixing up LOG_LINKS, we
+	   deal with the case where a pseudo use moved.  */
+	if (!bitmap_empty_p (new_regs_in_i2)
+	&& prev_nonnote_insn (i3) != i2
+	&& bitmap_first_set_bit (new_regs_in_i2) < FIRST_PSEUDO_REGISTER)
+	  {
+	undo_all ();
+	return 0;
+	  }
+}
+
   if (MAY_HAVE_DEBUG_INSNS)
 {
   struct undo *undo;
@@ -4494,6 +4600,45 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
 			NULL_RTX, NULL_RTX, NULL_RTX);
   }
 
+if (newi2pat)
+  {
+	bitmap_iterator iter;
+	unsigned int i;
+
+	/* See comments above where we calculate the bitmap.  */
+	

[PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Martin Liška]

Hello.

Following small series exclude some strings from pot files via
introduction of internal_error_cont function.

Patch can bootstrap and survives regression tests.

(Sorry for broken threading because my cover letter was rejected).

Martin

marxin (3):
  Introduce internal_error_cont function and use it in cfgrtl.c (PR
rtl-optimization/79856).
  Replace error with internal_error_cont in cgraph.c (PR ipa/79857).
  Regenerate gcc.pot.

 gcc/cfgrtl.c  |   349 +-
 gcc/cgraph.c  |   139 +-
 gcc/diagnostic-core.h | 1 +
 gcc/diagnostic.c  |16 +
 gcc/diagnostic.def| 1 +
 gcc/po/exgettext  | 6 +-
 gcc/po/gcc.pot| 14892 
 7 files changed, 7589 insertions(+), 7815 deletions(-)

Re: [PATCH] Install gcov-dump.

[Richard Biener]

On March 15, 2017 11:19:24 AM GMT+01:00, "Martin Liška"  wrote:
>On 03/14/2017 06:31 PM, Matthias Klose wrote:
>> On 14.03.2017 15:15, Richard Biener wrote:
>>> On Tue, Mar 14, 2017 at 1:30 PM, Martin Liška 
>wrote:
 Tested on my local machine that's properly installed.

 Ready for trunk?
>>>
>>> Ok.
>>>
>>> Richard.
>>
>> shouldn't that go to the active branches as well?
>>
>> Matthias
>>
>
>I would vote for that. However it may be bit strange that a new binary
>is added
>in GCC 6.4.
>
>What's maintainers' opinion about it?

No strong opinion but if Matthias would like to see it, fine.

Richard.

>Martin

Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[Janne Blomqvist]

On Tue, Mar 14, 2017 at 10:05 AM, Janne Blomqvist
 wrote:
> On Tue, Mar 14, 2017 at 6:32 AM, NightStrike  wrote:
>> On Mon, Mar 13, 2017 at 5:01 AM, Janne Blomqvist
>>  wrote:
>>> On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
>>>  wrote:
 On Sun, Mar 12, 2017 at 7:26 PM, NightStrike  wrote:
> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>  wrote:
>> Don't try to use rand_s on CYGWIN
>>
>> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
>> defined even though rand_s is not available. Thus add an extra check
>> for __CYGWIN__.
>>
>> Thanks to Tim Prince and Nightstrike for bringing this issue to my 
>> attention.
>>
>> Committed as r245755.
>>
>> 2017-02-27  Janne Blomqvist  
>>
>> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
>> CYGWIN.
>
> 1) There was no patch attached to the email.

 Oh, sorry. Well, you can see it at
 https://gcc.gnu.org/viewcvs/gcc?view=revision=245755
>>
>> Thanks.  You know, this is actually better than attaching a patch (as
>> a general thing for emails sent after things are already committed),
>> as there can be no difference between what was emailed and what was
>> committed.
>>
> 2) As mentioned on IRC, I don't think this is the right fix.  The real
> problem is that time_1.h includes windows.h on CYGWIN, which it
> shouldn't be doing.  This then pollutes the translation unit with all
> sorts of MINGW-isms that aren't exactly appropriate for cygwin.
> Removing the include in time_1.h and then adjusting a few ifdefs in
> system_clock.c that also had the same bug fixes the problem.  The
> testsuite is running right now on this.

 It used to be something like that, but IIRC there were some complaints
 about SYSTEM_CLOCK on cygwin that were due to the cygwin
 clock_gettime() or something like that, and after some discussion with
 someone who knows something about cygwin/mingw (since you apparently
 have no memory of it, I guess it was Kai), it was decided to use
 GetTickCount & QPC also on cygwin.
>>>
>>> I searched a bit, and it seems the culprit is the thread starting at
>>>
>>> https://gcc.gnu.org/ml/fortran/2013-04/msg00033.html
>>>
>>> So it turned out that clock_gettime(CLOCK_MONOTONIC, ...) always
>>> returned 0 on cygwin, hence the code was changed to use the windows
>>> API functions GetTickCount and QPC also on cygwin at
>>>
>>> https://gcc.gnu.org/ml/fortran/2013-04/msg00124.html
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
>>
>> That all led me to this thread:
>>
>> https://cygwin.com/ml/cygwin/2013-04/msg00184.html
>>
>> which led me to:
>>
>> https://cygwin.com/ml/cygwin/2013-04/msg00191.html
>>
>> where Corinna fixed Angelo's original issue that sparked the whole
>> thing.  So, from my perspective, Cygwin hasn't had this problem in
>> about 4 years.
>>
>> To be complete, though, I took Angelo's original code and compiled it
>> with a GCC built with the change I suggested, and I received this:
>>
>> $ ./a.exe
>>9.50646996E-02  0.435180306  0.939791977  0.851783216
>> 0.308901191  0.447312355  0.766363919  0.163527727
>> 1.25432014E-02
>>
>> $ ./a.exe
>>   0.445786893   9.30446386E-03  0.880381405  0.123394549
>> 1.23693347E-02  0.485788047  0.623361290  0.921140671
>> 0.119319797
>>
>> $ ./a.exe
>>   0.378171027  0.439836979  0.440582573   1.17767453E-02
>> 0.427448869  0.530438244  0.182108700  0.147965968
>> 0.668991745
>>
>> $ ./a.exe
>>2.73125172E-02  0.916011810  0.854288757  0.913502872
>> 0.508077919  0.210798383   8.76839161E-02  0.120695710
>> 0.337186754
>>
>>
>> I then tried Janus' enhanced version from
>> https://gcc.gnu.org/ml/fortran/2013-04/msg00034.html
>>
>> $ ./a.exe
>>  n=  33
>>  clock:   744091787
>>  seed:744091787   744091824   744091861   744091898   744091935
>> 744091972   744092009   744092046   744092083   744092120   744092157
>>  744092194   744092231   744092268   744092305   744092342   744092379
>>   744092416   744092453   744092490   744092527   744092564
>> 744092601   744092638   744092675   744092712   744092749   744092786
>>  744092823   744092860   744092897   744092934   744092971
>>  random:   0.801897824  0.180594921  0.280960143
>> 8.65536928E-03  0.122029424  0.473693788  0.161536098
>> 0.228073180  0.441518903
>>
>> $ ./a.exe
>>  n=  33
>>  clock:   744093409
>>  seed:744093409   744093446   744093483   744093520   744093557
>> 744093594   744093631   744093668   744093705   744093742   744093779
>>  744093816   744093853   744093890   744093927   744093964   744094001
>>   744094038   744094075   744094112   

[PATCH 1/3] Introduce internal_error_cont function and use it in cfgrtl.c (PR rtl-optimization/79856).

[marxin]

gcc/ChangeLog:

2017-03-13  Martin Liska  

PR rtl-optimization/79856
* cfgrtl.c (try_redirect_by_replacing_jump): Fix GNU coding
style.
(fixup_partition_crossing): Likewise.
(fixup_new_cold_bb): Likewise.
(emit_barrier_after_bb): Likewise.
(force_nonfallthru_and_redirect): Likewise.
(last_bb_in_partition): Likewise.
(rtl_split_edge): Likewise.
(commit_one_edge_insertion): Likewise.
(print_rtl_with_bb): Likewise.
(find_partition_fixes): Use internal_error_cont instead of
error.
(verify_hot_cold_block_grouping): Likewise.
(rtl_verify_edges): Likewise.
(rtl_verify_bb_insns): Likewise.
(rtl_verify_bb_pointers): Likewise.
(rtl_verify_bb_insn_chain): Likewise.
(rtl_verify_fallthru): Likewise.
(purge_dead_edges): Fix GNU coding style.
(fixup_abnormal_edges): Likewise.
(fixup_reorder_chain): Likewise.
(duplicate_insn_chain): Likewise.
* diagnostic-core.h (internal_error_cont): Declare new function.
* diagnostic.c (diagnostic_action_after_output): Handle
newly added DK_INTERNAL_ERROR.
(internal_error_cont): New function.
* diagnostic.def (DK_INTERNAL_ERROR): New enum value.
---
 gcc/cfgrtl.c  | 349 ++
 gcc/diagnostic-core.h |   1 +
 gcc/diagnostic.c  |  16 +++
 gcc/diagnostic.def|   1 +
 4 files changed, 201 insertions(+), 166 deletions(-)

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index cafa38d35b0..840538c0bb6 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1130,7 +1130,7 @@ try_redirect_by_replacing_jump (edge e, basic_block 
target, bool in_cfglayout)
  rtx_insn *new_insn = BB_END (src);
 
  update_bb_for_insn_chain (NEXT_INSN (BB_END (src)),
-   PREV_INSN (barrier), src);
+   PREV_INSN (barrier), src);
 
  SET_NEXT_INSN (PREV_INSN (new_insn)) = NEXT_INSN (new_insn);
  SET_PREV_INSN (NEXT_INSN (new_insn)) = PREV_INSN (new_insn);
@@ -1342,22 +1342,22 @@ fixup_partition_crossing (edge e)
 {
   e->flags &= ~EDGE_CROSSING;
   /* Remove the section crossing note from jump at end of
- src if it exists, and if no other successors are
- still crossing.  */
+src if it exists, and if no other successors are
+still crossing.  */
   if (JUMP_P (BB_END (e->src)) && CROSSING_JUMP_P (BB_END (e->src)))
-{
-  bool has_crossing_succ = false;
-  edge e2;
-  edge_iterator ei;
-  FOR_EACH_EDGE (e2, ei, e->src->succs)
-{
-  has_crossing_succ |= (e2->flags & EDGE_CROSSING);
-  if (has_crossing_succ)
-break;
-}
-  if (!has_crossing_succ)
+   {
+ bool has_crossing_succ = false;
+ edge e2;
+ edge_iterator ei;
+ FOR_EACH_EDGE (e2, ei, e->src->succs)
+   {
+ has_crossing_succ |= (e2->flags & EDGE_CROSSING);
+ if (has_crossing_succ)
+   break;
+   }
+ if (!has_crossing_succ)
CROSSING_JUMP_P (BB_END (e->src)) = 0;
-}
+   }
 }
 }
 
@@ -1387,14 +1387,14 @@ fixup_new_cold_bb (basic_block bb)
   FOR_EACH_EDGE (e, ei, bb->succs)
 {
   /* We can't have fall-through edges across partition boundaries.
- Note that force_nonfallthru will do any necessary partition
- boundary fixup by calling fixup_partition_crossing itself.  */
+Note that force_nonfallthru will do any necessary partition
+boundary fixup by calling fixup_partition_crossing itself.  */
   if ((e->flags & EDGE_FALLTHRU)
-  && BB_PARTITION (bb) != BB_PARTITION (e->dest)
+ && BB_PARTITION (bb) != BB_PARTITION (e->dest)
  && e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
-force_nonfallthru (e);
+   force_nonfallthru (e);
   else
-fixup_partition_crossing (e);
+   fixup_partition_crossing (e);
 }
 }
 
@@ -1445,25 +1445,25 @@ emit_barrier_after_bb (basic_block bb)
 {
   rtx_barrier *barrier = emit_barrier_after (BB_END (bb));
   gcc_assert (current_ir_type () == IR_RTL_CFGRTL
-  || current_ir_type () == IR_RTL_CFGLAYOUT);
+ || current_ir_type () == IR_RTL_CFGLAYOUT);
   if (current_ir_type () == IR_RTL_CFGLAYOUT)
 {
   rtx_insn *insn = unlink_insn_chain (barrier, barrier);
 
   if (BB_FOOTER (bb))
{
-  rtx_insn *footer_tail = BB_FOOTER (bb);
-
-  while (NEXT_INSN (footer_tail))
-footer_tail = NEXT_INSN (footer_tail);
-  if (!BARRIER_P (footer_tail))
-{
-  SET_NEXT_INSN (footer_tail) = insn;
-  SET_PREV_INSN (insn) = footer_tail;
-}
+ rtx_insn *footer_tail = BB_FOOTER 

[PATCH 2/3] Replace error with internal_error_cont in cgraph.c (PR ipa/79857).

[marxin]

gcc/ChangeLog:

2017-03-13  Martin Liska  

PR ipa/79857
* cgraph.c (cgraph_edge::verify_count_and_frequency):
Replace error with internal_error_cont.
(cgraph_node::verify_node): Likewise.
---
 gcc/cgraph.c | 139 ---
 1 file changed, 76 insertions(+), 63 deletions(-)

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 839388496ee..f30a280de8c 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2981,17 +2981,17 @@ cgraph_edge::verify_count_and_frequency ()
   bool error_found = false;
   if (count < 0)
 {
-  error ("caller edge count is negative");
+  internal_error_cont ("caller edge count is negative");
   error_found = true;
 }
   if (frequency < 0)
 {
-  error ("caller edge frequency is negative");
+  internal_error_cont ("caller edge frequency is negative");
   error_found = true;
 }
   if (frequency > CGRAPH_FREQ_MAX)
 {
-  error ("caller edge frequency is too large");
+  internal_error_cont ("caller edge frequency is too large");
   error_found = true;
 }
   return error_found;
@@ -3075,55 +3075,56 @@ cgraph_node::verify_node (void)
   for (e = callees; e; e = e->next_callee)
 if (e->aux)
   {
-   error ("aux field set for edge %s->%s",
-  identifier_to_locale (e->caller->name ()),
-  identifier_to_locale (e->callee->name ()));
+   internal_error_cont ("aux field set for edge %s->%s",
+identifier_to_locale (e->caller->name ()),
+identifier_to_locale (e->callee->name ()));
error_found = true;
   }
   if (count < 0)
 {
-  error ("execution count is negative");
+  internal_error_cont ("execution count is negative");
   error_found = true;
 }
   if (global.inlined_to && same_comdat_group)
 {
-  error ("inline clone in same comdat group list");
+  internal_error_cont ("inline clone in same comdat group list");
   error_found = true;
 }
   if (!definition && !in_other_partition && local.local)
 {
-  error ("local symbols must be defined");
+  internal_error_cont ("local symbols must be defined");
   error_found = true;
 }
   if (global.inlined_to && externally_visible)
 {
-  error ("externally visible inline clone");
+  internal_error_cont ("externally visible inline clone");
   error_found = true;
 }
   if (global.inlined_to && address_taken)
 {
-  error ("inline clone with address taken");
+  internal_error_cont ("inline clone with address taken");
   error_found = true;
 }
   if (global.inlined_to && force_output)
 {
-  error ("inline clone is forced to output");
+  internal_error_cont ("inline clone is forced to output");
   error_found = true;
 }
   for (e = indirect_calls; e; e = e->next_callee)
 {
   if (e->aux)
{
- error ("aux field set for indirect edge from %s",
+ internal_error_cont ("aux field set for indirect edge from %s",
 identifier_to_locale (e->caller->name ()));
  error_found = true;
}
   if (!e->indirect_unknown_callee
  || !e->indirect_info)
{
- error ("An indirect edge from %s is not marked as indirect or has "
-"associated indirect_info, the corresponding statement is: ",
-identifier_to_locale (e->caller->name ()));
+ internal_error_cont ("An indirect edge from %s is not marked as "
+  "indirect or has associated indirect_info, "
+  "the corresponding statement is: ",
+  identifier_to_locale (e->caller->name ()));
  cgraph_debug_gimple_stmt (this_cfun, e->call_stmt);
  error_found = true;
}
@@ -3136,8 +3137,9 @@ cgraph_node::verify_node (void)
   if (check_comdat
  && !in_same_comdat_group_p (e->caller))
{
- error ("comdat-local function called by %s outside its comdat",
-identifier_to_locale (e->caller->name ()));
+ internal_error_cont ("comdat-local function called by %s outside "
+  "its comdat",
+  identifier_to_locale (e->caller->name ()));
  error_found = true;
}
   if (!e->inline_failed)
@@ -3146,19 +3148,20 @@ cgraph_node::verify_node (void)
  != (e->caller->global.inlined_to
  ? e->caller->global.inlined_to : e->caller))
{
- error ("inlined_to pointer is wrong");
+ internal_error_cont ("inlined_to pointer is wrong");
  error_found = true;
}
  if (callers->next_caller)
{
- error ("multiple inline callers");
+ internal_error_cont ("multiple inline callers");
  error_found = true;
}
   

Fix C6X hwloop issue

[Bernd Schmidt]

This fixes a failure in the testsuite. When we transform the doloop 
pattern, the decrement of the old iteration register goes away, which is 
a problem if it's used after the loop (where it should have the value zero).


Committed.


Bernd
	* config/c6x/c6x.c (predicate_insn): Avoid rtl sharing failure.
	(hwloop_optimize): Handle case where the old iteration reg is used
	after the loop.

Index: gcc/config/c6x/c6x.c
===
--- gcc/config/c6x/c6x.c	(revision 245685)
+++ gcc/config/c6x/c6x.c	(working copy)
@@ -5788,8 +5789,9 @@ hwloop_optimize (hwloop_info loop)
   start_sequence ();
 
   insn = emit_insn (gen_mvilc (loop->iter_reg));
+  if (loop->iter_reg_used_outside)
+insn = emit_move_insn (loop->iter_reg, const0_rtx);
   insn = emit_insn (gen_sploop (GEN_INT (sp_ii)));
-
   seq = get_insns ();
 
   if (!single_succ_p (entry_bb) || vec_safe_length (loop->incoming) > 1)

[PATCH, i386]: Fix PR 80019, ICE in ix86_vector_duplicate_value

[Uros Bizjak]

2017-03-15  Uros Bizjak  

PR target/80019
* config/i386/i386.c (ix86_vector_duplicate_value): Create
subreg of inner mode for values already in registers.

testsuite/ChangeLog:

2017-03-15  Uros Bizjak  

PR target/80019
* gcc.target/i386/pr80019.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline, will be backported to other release branches.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 246156)
+++ config/i386/i386.c  (working copy)
@@ -42571,10 +42571,16 @@ ix86_vector_duplicate_value (machine_mode mode, rt
   if (recog_memoized (insn) < 0)
 {
   rtx_insn *seq;
+  machine_mode innermode = GET_MODE_INNER (mode);
+  rtx reg;
+
   /* If that fails, force VAL into a register.  */
 
   start_sequence ();
-  XEXP (dup, 0) = force_reg (GET_MODE_INNER (mode), val);
+  reg = force_reg (innermode, val);
+  if (GET_MODE (reg) != innermode)
+   reg = gen_lowpart (innermode, reg);
+  XEXP (dup, 0) = reg;
   seq = get_insns ();
   end_sequence ();
   if (seq)
Index: testsuite/gcc.target/i386/pr80019.c
===
--- testsuite/gcc.target/i386/pr80019.c (nonexistent)
+++ testsuite/gcc.target/i386/pr80019.c (working copy)
@@ -0,0 +1,13 @@
+/* PR target/80019 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mxop -mavx2" } */
+
+typedef char v16qi __attribute__ ((vector_size (16)));
+
+extern v16qi b, c;
+
+void
+foo (int e)
+{
+  b = c << e;
+}

[committed] C PATCH to remove a redundant line

[Marek Polacek]

We set ENUM_LOC, and then overwrite it without ever using it.  Remove the line.

Bootstrapped/regtested on x86_64-linux, applying to trunk.

2017-03-15  Marek Polacek  

* c-parser.c (c_parser_enum_specifier): Remove redundant line.

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 46883e2..5bc238b 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -2694,7 +2694,6 @@ c_parser_enum_specifier (c_parser *parser)
   location_t enum_loc;
   location_t ident_loc = UNKNOWN_LOCATION;  /* Quiet warning.  */
   gcc_assert (c_parser_next_token_is_keyword (parser, RID_ENUM));
-  enum_loc = c_parser_peek_token (parser)->location;
   c_parser_consume_token (parser);
   attrs = c_parser_attributes (parser);
   enum_loc = c_parser_peek_token (parser)->location;

Marek

Re: [PATCH doc] use "cannot" consistently

[Richard Kenner]

> First, I agree that the less formal language is becoming more
> acceptable.  Some style guides explicitly allow contractions,
> but others advise against them.  The technical specifications
> that significant parts of GCC aim to conform to, and those I
> happen  to work with the most closely (the C, C++, and POSIX
> standards), avoid them.  The IEEE Editorial Style Manual
> recommends against using them.  The author of Engineer's Guide
> to Technical Writing, Kenneth Budinski, equates them with slang.

How old are those documents?  More recently, see

http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm
https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/

The latter references other documents, which advocate for more use of
contractions even in formal writing.

> I personally don't feel too strongly about it, but the change
> seems like an opportunity to improve not just the style of
> the manual but also increase its consistency.  I could see
> one being indifferent to such changes but I have trouble
> understanding how they could be viewed as the wrong direction.
> What is your rationale against it and what would you consider
> the right direction for the manual?

I think it's the wrong direction because I'd be in favor of gradually
*introducing* contractions into to the manual instead of a change that
eliminates them.  I wouldn't be against a change that went in the other
direction (used contractions consistently), but it would be good a large
change, so I'm not advocating for doing that, but just instead using
contractions in all new material and when modifying old material for
other reasons.

Re: [PATCH] Suppress compiler warning in libgcc/unwind-seh.c

[JonY]

On 03/15/2017 04:12 AM, Jeff Law wrote:
> On 03/01/2017 04:36 AM, JonY wrote:
>> Patch OK?
>>
>> ChangeLog:
>> * unwind-seh.c: Suppress warnings for RtlUnwindEx() calls.
> You know this stuff better than anyone else working with GCC.  If you
> think this is the right thing to do for the SEH code, go for it.
> 
> jeff
> 
> 

Already applied to trunk, thanks.




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Install gcov-dump.

[Martin Liška]

On 03/14/2017 06:31 PM, Matthias Klose wrote:

On 14.03.2017 15:15, Richard Biener wrote:

On Tue, Mar 14, 2017 at 1:30 PM, Martin Liška  wrote:

Tested on my local machine that's properly installed.

Ready for trunk?


Ok.

Richard.


shouldn't that go to the active branches as well?

Matthias



I would vote for that. However it may be bit strange that a new binary is added
in GCC 6.4.

What's maintainers' opinion about it?

Martin

Re: [PATCH] MPX: fix PR middle-end/79753

[Martin Liška]

On 03/14/2017 11:27 PM, Ilya Enkovich wrote:

2017-03-10 16:15 GMT+03:00 Martin Liška :

Hello.

Currently, __builtin_ia32_bndret is used for all functions that have non-void
return type. I think the right fix is to return bounds just for a bounded type.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Martin


Hi,

The fix makes sense and allows you to pass the test but it seems like we
still have the issue in inlining which can result in bndret call with wrong arg.


Hi.

The test I added does probably what you mean: a return value of integer is 
casted
to a pointer type. Or?


Do you avoid all such cases by this fix? Can we still have similar problem
if cast function with integer return type to a function with pointer return type
and the inline the call (not sure if we can inline such calls)?

I think this fix still should go to trunk anyway.


Good, may I consider this as patch approval?
Thanks,
Martin



Thanks,
Ilya

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Martin Liška]

On 03/15/2017 12:58 AM, Ilya Enkovich wrote:

2017-03-13 16:33 GMT+03:00 Martin Liška :

On 03/13/2017 02:07 PM, Richard Biener wrote:

No, that can't happen.  I said that for example for

struct S { ... } s;
foo (s);

pass_by_reference may be true but on gimple you see a struct s as
actual argument.  I'm not sure
what chkp_find_bounds does to 's' in this case.  Like if floats are
passed by reference you might
see a REAL_CST passed to chkp_find_bounds but in reality it will get a
pointer (with bounds
according to the argument slot that was used).


Currently constants have invalid bounds assigned. Thus I guess it can't cause a 
trouble
when such constant is used as a pointer. Anyhow, the discrepancy should be 
handled better.

Last question related to the patch. May I at least install the part which adds 
{COMPLEX,VECTOR}_CSTs
handling as it can happen with -mabi=ms (where formal and actual args do 
match)? Or using -mabi=ms + CHKP
does not make sense at all?


Hi,

Originally casted function calls were not taken into account by
instrumentation pass and it
caused such sloppy handling of these casts later. It would be nice to
revise this code.


Hi.

Yep, code revisiting would be needed in this area.



Meanwhile your fix should go to trunk. CHKP instrumentation pass is
supposed to be target
independent and therefore shouldn't rely on any ABI.


As you are MPX maintainer, may I consider that as patch approval?

Martin



Thanks,
Ilya



Martin

Re: [PATCH 2] Fix multiple target clones nodes (PR lto/66295).

[Martin Liška]

On 03/15/2017 10:30 AM, Rainer Orth wrote:

Hi Martin,


This is a small follow-up patch, where local.local flag should be also dropped
for a default implementation.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?


the testcase causes

WARNING: profopt.exp does not support dg-error

I suspect it can just as well go into gcc.dg with


Thanks for pointing out. As I read the test-case, the dg-error is not needed.
I'm going to install following patch as obvious.

Martin



/* { dg-require-profiling "-fprofile-generate" } */

and -fprofile-generate added to dg-options.

Rainer



>From 3ac3656787ded319f19c347a3576474adc48a6d9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 15 Mar 2017 11:03:27 +0100
Subject: [PATCH] Removed unused dg-error.

gcc/testsuite/ChangeLog:

2017-03-15  Martin Liska  

	* gcc.dg/tree-prof/pr66295.c: Removed unused dg-error.
---
 gcc/testsuite/gcc.dg/tree-prof/pr66295.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
index 1ab7e6c8f64..b90ef84ed10 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
@@ -11,7 +11,7 @@ foo (double *__restrict a, double *__restrict b, int n)
 }
 
 double
-bar (double *__restrict a, double *__restrict b, int n)	/* { dg-error "attribute\[^\n\r]*foo\[^\n\r]* is unknown" } */
+bar (double *__restrict a, double *__restrict b, int n)
 {
   double s;
   int i;
-- 
2.11.1

Re: [PATCH][AArch64] Implement ALU_BRANCH fusion

[Hurugalawadi, Naveen]

Hi Kyrill,

>> I suggest you reword the whole comment and not talk about particular CPUs
>> but rather about the kinds of instructions you want to fuse

Modified as per the comments. Had modified the earlier version of patch
which had the vulcan reservation before James comments.

Please find attached the modified patch with comments incorporated.

Thanks,
Naveen


diff --git a/gcc/config/aarch64/aarch64-fusion-pairs.def b/gcc/config/aarch64/aarch64-fusion-pairs.def
index f0e6dbc..300cd00 100644
--- a/gcc/config/aarch64/aarch64-fusion-pairs.def
+++ b/gcc/config/aarch64/aarch64-fusion-pairs.def
@@ -34,5 +34,6 @@ AARCH64_FUSION_PAIR ("movk+movk", MOVK_MOVK)
 AARCH64_FUSION_PAIR ("adrp+ldr", ADRP_LDR)
 AARCH64_FUSION_PAIR ("cmp+branch", CMP_BRANCH)
 AARCH64_FUSION_PAIR ("aes+aesmc", AES_AESMC)
+AARCH64_FUSION_PAIR ("alu+branch", ALU_BRANCH)
 
 #undef AARCH64_FUSION_PAIR
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index a069427..3af0b1a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -792,7 +792,8 @@ static const struct tune_params thunderx2t99_tunings =
   _approx_modes,
   4, /* memmov_cost.  */
   4, /* issue_rate.  */
-  (AARCH64_FUSE_CMP_BRANCH | AARCH64_FUSE_AES_AESMC), /* fusible_ops  */
+  (AARCH64_FUSE_CMP_BRANCH | AARCH64_FUSE_AES_AESMC
+   | AARCH64_FUSE_ALU_BRANCH), /* fusible_ops  */
   16,	/* function_align.  */
   8,	/* jump_align.  */
   16,	/* loop_align.  */
@@ -13981,6 +13982,35 @@ aarch_macro_fusion_pair_p (rtx_insn *prev, rtx_insn *curr)
 return true;
 }
 
+  if (aarch64_fusion_enabled_p (AARCH64_FUSE_ALU_BRANCH)
+  && any_condjump_p (curr))
+{
+  /* Fuse ALU operations followed by conditional branch instruction.  */
+  switch (get_attr_type (prev))
+	{
+	case TYPE_ALU_IMM:
+	case TYPE_ALU_SREG:
+	case TYPE_ADC_REG:
+	case TYPE_ADC_IMM:
+	case TYPE_ADCS_REG:
+	case TYPE_ADCS_IMM:
+	case TYPE_LOGIC_REG:
+	case TYPE_LOGIC_IMM:
+	case TYPE_CSEL:
+	case TYPE_ADR:
+	case TYPE_MOV_IMM:
+	case TYPE_SHIFT_REG:
+	case TYPE_SHIFT_IMM:
+	case TYPE_BFM:
+	case TYPE_RBIT:
+	case TYPE_REV:
+	case TYPE_EXTEND:
+	  return true;
+
+	default:;
+	}
+}
+
   return false;
 }
 

Re: [PATCH 3/3] Introduce IntegerRange for options (PR driver/79659).

[Martin Liška]

Huh, I forgot to attach the patch.

Martin
>From bb89456e6cecfa9497cf8e265d2083e762d5bc3e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 27 Feb 2017 14:07:03 +0100
Subject: [PATCH] Introduce IntegerRange for options (PR driver/79659).

gcc/ChangeLog:

2017-02-28  Martin Liska  

	PR driver/79659
	* common.opt: Add IntegerRange to various options.
	* opt-functions.awk (integer_range_info): New function.
	* optc-gen.awk: Add integer_range_info to cl_options struct.
	* opts-common.c (decode_cmdline_option): Handle
	CL_ERR_INT_RANGE_ARG.
	(cmdline_handle_error): Likewise.
	* opts.c (print_filtered_help): Show valid interval in
	when --help is provided.
	* opts.h (struct cl_option): Add range_min and range_max fields.
	* config/i386/i386.opt: Add IntegerRange for -mbranch-cost.

gcc/c-family/ChangeLog:

2017-02-28  Martin Liska  

	PR driver/79659
	* c.opt: Add IntegerRange to various options.

gcc/testsuite/ChangeLog:

2017-02-28  Martin Liska  

	PR driver/79659
	* g++.dg/opt/pr79659.C: New test.
---
 gcc/c-family/c.opt | 20 ++--
 gcc/common.opt |  8 
 gcc/config/i386/i386.opt   |  4 ++--
 gcc/opt-functions.awk  | 11 +++
 gcc/optc-gen.awk   |  4 ++--
 gcc/opts-common.c  | 12 
 gcc/opts.c |  9 +
 gcc/opts.h |  9 +++--
 gcc/testsuite/g++.dg/opt/pr79659.C |  5 +
 9 files changed, 62 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/opt/pr79659.C

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index cf459ab4427..d071c180bd1 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -529,7 +529,7 @@ C ObjC C++ ObjC++ Var(warn_format_nonliteral) Warning LangEnabledBy(C ObjC C++ O
 Warn about format strings that are not literals.
 
 Wformat-overflow
-C ObjC C++ LTO ObjC++ Warning Alias(Wformat-overflow=, 1, 0)
+C ObjC C++ LTO ObjC++ Warning Alias(Wformat-overflow=, 1, 0) IntegerRange(0, 2)
 Warn about function calls with format strings that write past the end
 of the destination region.  Same as -Wformat-overflow=1.
 
@@ -555,16 +555,16 @@ C ObjC C++ ObjC++ Var(warn_format_zero_length) Warning LangEnabledBy(C ObjC C++
 Warn about zero-length formats.
 
 Wformat=
-C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 1, 0)
+C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 1, 0) IntegerRange(0, 2)
 Warn about printf/scanf/strftime/strfmon format string anomalies.
 
 Wformat-overflow=
-C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_format_overflow) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0)
+C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_format_overflow) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0) IntegerRange(0, 2)
 Warn about function calls with format strings that write past the end
 of the destination region.
 
 Wformat-truncation=
-C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format_trunc) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0)
+C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_format_trunc) Warning LangEnabledBy(C ObjC C++ ObjC++,Wformat=, warn_format >= 1, 0) IntegerRange(0, 2)
 Warn about calls to snprintf and similar functions that truncate output.
 
 Wignored-qualifiers
@@ -712,7 +712,7 @@ Warn about buffer overflow in string manipulation functions like memcpy
 and strcpy.
 
 Wstringop-overflow=
-C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow) Init(2) Warning
+C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow) Init(2) Warning IntegerRange(0, 4)
 Under the control of Object Size type, warn about buffer overflow in string
 manipulation functions like memcpy and strcpy.
 
@@ -908,7 +908,7 @@ C++ Warning Alias(Wplacement-new=, 1, 0)
 Warn for placement new expressions with undefined behavior.
 
 Wplacement-new=
-C++ Joined RejectNegative UInteger Var(warn_placement_new) Init(-1) Warning
+C++ Joined RejectNegative UInteger Var(warn_placement_new) Init(-1) Warning IntegerRange(0, 2)
 Warn for placement new expressions with undefined behavior.
 
 Wredundant-decls
@@ -948,7 +948,7 @@ C ObjC C++ ObjC++ Warning Alias(Wshift-overflow=, 1, 0)
 Warn if left shift of a signed value overflows.
 
 Wshift-overflow=
-C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_shift_overflow) Init(-1) Warning
+C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_shift_overflow) Init(-1) Warning IntegerRange(0, 2)
 Warn if left shift of a signed value overflows.
 
 Wshift-count-negative
@@ -988,11 +988,11 @@ C ObjC Var(warn_strict_prototypes) Warning
 Warn about unprototyped function declarations.
 
 Wstrict-aliasing=
-C ObjC C++ 

Re: [PATCH 2] Fix multiple target clones nodes (PR lto/66295).

[Rainer Orth]

Hi Martin,

> This is a small follow-up patch, where local.local flag should be also dropped
> for a default implementation.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

the testcase causes

WARNING: profopt.exp does not support dg-error

I suspect it can just as well go into gcc.dg with

/* { dg-require-profiling "-fprofile-generate" } */

and -fprofile-generate added to dg-options.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH][AArch64] Implement ALU_BRANCH fusion

[Kyrill Tkachov]

Hi Naveen,

On 15/03/17 05:32, Hurugalawadi, Naveen wrote:

Hi James,


My reason for asking is that the instruction fusion implemented in LLVM
( lib/Target/AArch64/AArch64MacroFusion.cpp::shouldScheduleAdjacent )

Sorry. There seems to be some confusion in the branch instructions.
The branch should be conditional for ALU_BRANCH fusion.

Please find attached the modified patch that fuses ALU instructions and
conditional branches.

Bootstrapped and Regression tested on aarch64-thunder-linux.
Please review the patch and let us know if its okay?

Thanks,
Naveen
 


+  if (aarch64_fusion_enabled_p (AARCH64_FUSE_ALU_BRANCH)
+  && any_condjump_p (curr))
+{
+  /* These types correspond to the reservation "vulcan_alu_basic" for
+Broadcom Vulcan: these are ALU operations that produce a single uop
+during instruction decoding.  */

The comment here still looks wrong. There is no vulcan_alu_basic reservation in 
any of the scheduling models.
I suggest you reword the whole comment and not talk about particular CPUs, but 
rather about the kinds of instructions
you want to fuse. If a reader wants to know which CPUs enable this fusion they 
should be looking at the CPU tuning structures
rather than reading the comments here.

Kyrill