Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/3/20 4:07 PM, Patrick Palka wrote:

On Fri, 3 Apr 2020, Jason Merrill wrote:


On 4/2/20 7:40 PM, Patrick Palka wrote:

+  /* Prefer the outermost matching object, but don't cross
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.  */
+  if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor))
+if (tree parent_ob = lookup_placeholder (ctx->parent, lval, type))
+  return parent_ob;


Instead of recursing here, would it work to replace the loop at the end with
tail recursion?


Do you mean something like the following?

   static tree
   lookup_placeholder (const constexpr_ctx *ctx, bool lval, tree type)
   {
 if (!ctx)
   return NULL_TREE;

 tree ob = ctx->object;
 if (ob && same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (ob), type))
   return obj;
 else if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor))
   return lookup_placeholder (ctx->parent, lval, type);
 else
   return NULL_TREE;
   }

I think we would need to set ctx->parent in more places in order for this to
work, so that each node in the path to the innermost suboject is represented by
a constexpr_ctx.


Hmm, true.  But given how it's currently set, the comment


+  /* The constexpr expansion context inside which this one is nested.


seems overly general; perhaps "the aggregate initialization context..."?

OK with that change.


Besides that, using tail recursion would, IIUC, mean that we would return the
innermost matching object, but I think we want to return the outermost matching
object (without crossing CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors) when
there might be more than one matching object.  For if a PLACEHOLDER_EXPR really
was meant to refer to an object other than this outermost object, then
presumably the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag would have already been
set on some suboject constructor and so we wouldn't have recursed to
this outermost object in the first place, if I'm understanding the flag
correctly.


Good point.

Jason



Re: [PATCH v2] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/3/20 4:12 PM, Jakub Jelinek wrote:

On Fri, Apr 03, 2020 at 03:02:58PM -0400, Jason Merrill via Gcc-patches wrote:

Or do we want a further wrapper, perhaps C++ FE only, that would do this
protected_set_expr_location_if_unset (stmt, locus)?


That sounds good to me.


So like this if it passes bootstrap/regtest?


OK.


2020-04-03  Jakub Jelinek  

PR debug/94441
* tree-iterator.h (expr_single): Declare.
* tree-iterator.c (expr_single): New function.
* tree.h (protected_set_expr_location_if_unset): Declare.
* tree.c (protected_set_expr_location): Use expr_single.
(protected_set_expr_location_if_unset): New function.

* parser.c (cp_parser_omp_for_loop): Use
protected_set_expr_location_if_unset.
* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.

* g++.dg/opt/pr94441.C: New test.

--- gcc/tree-iterator.h.jj  2020-04-02 12:53:41.556232418 +0200
+++ gcc/tree-iterator.h 2020-04-03 21:07:01.335933695 +0200
@@ -119,5 +119,6 @@ extern void append_to_statement_list (tr
  extern void append_to_statement_list_force (tree, tree *);
  extern tree expr_first (tree);
  extern tree expr_last (tree);
+extern tree expr_single (tree);
  
  #endif /* GCC_TREE_ITERATOR_H  */

--- gcc/tree-iterator.c.jj  2020-04-02 12:53:41.555232434 +0200
+++ gcc/tree-iterator.c 2020-04-03 21:07:01.335933695 +0200
@@ -354,4 +354,45 @@ expr_last (tree expr)
return expr;
  }
  
+/* If EXPR is a STATEMENT_LIST containing just DEBUG_BEGIN_STMTs and

+   a single other stmt, return that other stmt (recursively).
+   If it is a STATEMENT_LIST containing no non-DEBUG_BEGIN_STMTs or
+   multiple, return NULL_TREE.
+   Otherwise return EXPR.  */
+
+tree
+expr_single (tree expr)
+{
+  if (expr == NULL_TREE)
+return expr;
+
+  if (TREE_CODE (expr) == STATEMENT_LIST)
+{
+  /* With -gstatement-frontiers we could have a STATEMENT_LIST with
+DEBUG_BEGIN_STMT(s) and only a single other stmt, which with
+-g wouldn't be present and we'd have that single other stmt
+directly instead.  */
+  struct tree_statement_list_node *n = STATEMENT_LIST_HEAD (expr);
+  if (!n)
+   return NULL_TREE;
+  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT)
+   {
+ n = n->next;
+ if (!n)
+   return NULL_TREE;
+   }
+  expr = n->stmt;
+  do
+   {
+ n = n->next;
+ if (!n)
+   return expr_single (expr);
+   }
+  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT);
+  return NULL_TREE;
+}
+
+  return expr;
+}
+
  #include "gt-tree-iterator.h"
--- gcc/tree.h.jj   2020-01-31 19:18:02.643900799 +0100
+++ gcc/tree.h  2020-04-03 21:09:26.134805791 +0200
@@ -1203,6 +1203,7 @@ get_expr_source_range (tree expr)
  }
  
  extern void protected_set_expr_location (tree, location_t);

+extern void protected_set_expr_location_if_unset (tree, location_t);
  
  extern tree maybe_wrap_with_location (tree, location_t);
  
--- gcc/tree.c.jj	2020-04-03 15:41:34.442645256 +0200

+++ gcc/tree.c  2020-04-03 21:08:57.47740 +0200
@@ -5148,33 +5148,23 @@ protected_set_expr_location (tree t, loc
  SET_EXPR_LOCATION (t, loc);
else if (t && TREE_CODE (t) == STATEMENT_LIST)
  {
-  /* With -gstatement-frontiers we could have a STATEMENT_LIST with
-DEBUG_BEGIN_STMT(s) and only a single other stmt, which with
--g wouldn't be present and we'd have that single other stmt
-directly instead.  */
-  struct tree_statement_list_node *n = STATEMENT_LIST_HEAD (t);
-  if (!n)
-   return;
-  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT)
-   {
- n = n->next;
- if (!n)
-   return;
-   }
-  tree t2 = n->stmt;
-  do
-   {
- n = n->next;
- if (!n)
-   {
- protected_set_expr_location (t2, loc);
- return;
-   }
-   }
-  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT);
+  t = expr_single (t);
+  if (t && CAN_HAVE_LOCATION_P (t))
+   SET_EXPR_LOCATION (t, loc);
  }
  }
  
+/* Like PROTECTED_SET_EXPR_LOCATION, but only do that if T has

+   UNKNOWN_LOCATION.  */
+
+void
+protected_set_expr_location_if_unset (tree t, location_t loc)
+{
+  t = expr_single (t);
+  if (t && !EXPR_HAS_LOCATION (t))
+protected_set_expr_location (t, loc);
+}
+
  /* Data used when collecting DECLs and TYPEs for language data removal.  */
  
  class free_lang_data_d

--- gcc/cp/parser.c.jj  2020-04-02 12:53:41.542232631 +0200
+++ gcc/cp/parser.c 2020-04-03 21:11:39.675843324 +0200
@@ -39149,8 +39149,7 @@ cp_parser_omp_for_loop (cp_parser *parse
incr = cp_parser_omp_for_incr (parser, real_decl);
  else
incr = cp_parser_expression (parser);
- if (!EXPR_HAS_LOCATION (incr))
-   protected_set_expr_location (incr, input_location);
+ protected_set_expr_location_if_unset (incr, 

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/3/20 4:57 PM, Patrick Palka wrote:

On Fri, 3 Apr 2020, Patrick Palka wrote:


On Fri, 3 Apr 2020, Jason Merrill wrote:


On 4/2/20 2:19 PM, Patrick Palka wrote:

On Thu, 2 Apr 2020, Patrick Palka wrote:


This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression
do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR.  Evaluation of the initializer could add new
elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers
to
or assumptions about the CONSTRUCTOR's elements, and so these routines
should be
prepared for that.

To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the pointer to the constructor_elt's
through
which we're assigning, after it evaluates the initializer.  Care is taken
to
to make the common case where the initializer does not modify the
underlying
CONSTRUCTOR as fast as before.


Also, with this patch, I'm not totally sure but I think we might not
need the special preeval handling in cxx_eval_store_expression anymore.
I could try to remove it in a subsequent patch.


I think for C++17 order of evaluation it's better to keep preevaluating when
we can.


Sounds good.




gcc/cp/ChangeLog:

PR c++/94205
PR c++/94219
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
support for VECTOR_TYPEs, and optimizations for the common case)
from ...
(cxx_eval_store_expression): ... here.  Rename local variable
'changed_active_union_member_p' to 'activated_union_member_p'.  Record
the sequence of indexes into 'indexes' that yields the subobject we're
assigning to.  Record the integer offsets of the constructor indexes
we're assigning through into 'index_pos_hints'.  After evaluating the
initializer of the store expression, recompute 'valp' using 'indexes'
and 'index_pos_hints' as hints.
(cxx_eval_bare_aggregate): Tweak comments.  Use
get_or_insert_ctor_field
to recompute the pointer to the constructor_elt we're assigning
through
after evaluating each initializer.

gcc/testsuite/ChangeLog:

PR c++/94205
PR c++/94219
* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
* g++.dg/cpp1z/lambda-this5.C: New test.
---
   gcc/cp/constexpr.c| 252 +++---
   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C |  19 ++
   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C |  21 ++
   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C |  22 ++
   gcc/testsuite/g++.dg/cpp1z/lambda-this5.C |  11 +
   5 files changed, 228 insertions(+), 97 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C
   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C
   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C
   create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this5.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 91f0c3ba269..b4173c595f0 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3151,6 +3151,97 @@ find_array_ctor_elt (tree ary, tree dindex, bool
insert)
 return -1;
   }
   +/* Return a pointer to the constructor_elt of CTOR which matches INDEX.
If no
+   matching constructor_elt exists, then add one to CTOR.
+
+   As an optimization, if POS_HINT is non-negative then it is used as a
guess
+   for the (integer) index of the matching constructor_elt within CTOR.
*/
+
+static constructor_elt *
+get_or_insert_ctor_field (tree ctor, tree index, int pos_hint)
+{
+  tree type = TREE_TYPE (ctor);
+  if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
+{
+  CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
+  return _ELTS (ctor)->last();
+}
+  else if (TREE_CODE (type) == ARRAY_TYPE || TREE_CODE (type) ==
VECTOR_TYPE)
+{
+  HOST_WIDE_INT i = find_array_ctor_elt (ctor, index,
/*insert*/true);
+  gcc_assert (i >= 0);
+  constructor_elt *cep = CONSTRUCTOR_ELT (ctor, i);
+  gcc_assert (cep->index == NULL_TREE
+ || TREE_CODE (cep->index) != RANGE_EXPR);
+  return cep;
+}
+  else
+{
+  gcc_assert (TREE_CODE (index) == FIELD_DECL);
+
+  /* We must keep the CONSTRUCTOR's ELTS in FIELD order.
+Usually we meet initializers in that order, but it is
+possible for base types to be placed not in program
+order.  */
+  tree fields = TYPE_FIELDS (DECL_CONTEXT (index));
+  unsigned HOST_WIDE_INT idx = 0;
+  constructor_elt *cep = NULL;
+
+  /* First, check if we're changing the active member of a union.  */
+  if (TREE_CODE (type) == UNION_TYPE && CONSTRUCTOR_NELTS (ctor)
+ && CONSTRUCTOR_ELT (ctor, 0)->index != index)
+   vec_safe_truncate (CONSTRUCTOR_ELTS (ctor), 0);
+  /* 

Re: [PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/3/20 6:47 PM, Jakub Jelinek wrote:

Hi!

On the following testcase, in gdb ptype S::m1 prints long as return
type, but all the other methods show void instead.
PR53756 added code to add_type_attribute if the return type is
auto/decltype(auto), but we actually should look through references,
pointers and qualifiers.
Haven't included there DW_TAG_atomic_type, because I think at least ATM
one can't use that in C++.  Not sure about DW_TAG_array_type or what else
could be deduced.


http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a 
decl-specifier.


http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a 
template argument can be deduced.


Looks like you are missing arrays, pointers to members, and function 
return types.



Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-04-04  Domani Hannes  
Jakub Jelinek  

PR debug/94459
* dwarf2out.c (gen_subprogram_die): Look through references, pointers
and qualifiers when checking if in-class DIE had an 'auto' or
'decltype(auto)' return type to emit type again on definition.

* g++.dg/debug/pr94459.C: New test.

--- gcc/dwarf2out.c.jj  2020-04-03 10:04:44.704972108 +0200
+++ gcc/dwarf2out.c 2020-04-03 17:52:48.909483818 +0200
@@ -22905,11 +22905,19 @@ gen_subprogram_die (tree decl, dw_die_re
  != (unsigned) s.column))
add_AT_unsigned (subr_die, DW_AT_decl_column, s.column);
  
-	  /* If the prototype had an 'auto' or 'decltype(auto)' return type,

+ /* If the prototype had a cv 'auto' or 'decltype(auto)' return type,
 emit the real type on the definition die.  */
  if (is_cxx () && debug_info_level > DINFO_LEVEL_TERSE)
{
  dw_die_ref die = get_AT_ref (old_die, DW_AT_type);
+ while (die
+&& (die->die_tag == DW_TAG_reference_type
+|| die->die_tag == DW_TAG_rvalue_reference_type
+|| die->die_tag == DW_TAG_pointer_type
+|| die->die_tag == DW_TAG_const_type
+|| die->die_tag == DW_TAG_volatile_type
+|| die->die_tag == DW_TAG_restrict_type))
+   die = get_AT_ref (die, DW_AT_type);
  if (die == auto_die || die == decltype_auto_die)
add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
TYPE_UNQUALIFIED, false, context_die);
--- gcc/testsuite/g++.dg/debug/pr94459.C.jj 2020-04-03 18:06:28.234725520 
+0200
+++ gcc/testsuite/g++.dg/debug/pr94459.C2020-04-03 18:05:59.287104932 
+0200
@@ -0,0 +1,49 @@
+// PR debug/94459
+// { dg-do compile { target c++11 } }
+// { dg-options "-g -dA" }
+
+template 
+struct S
+{
+  T v;
+  S () : v (0) {}
+  auto m1 () { return v; }
+  auto  () { return v; }
+  auto & () { return (T&&)v; }
+  const auto m4 () { return v; }
+  const auto  () { return v; }
+  const auto & () { return (T&&)v; }
+  volatile auto m7 () { return v; }
+  volatile auto  () { return v; }
+  volatile auto & () { return (T&&)v; }
+  volatile const auto m10 () { return v; }
+  volatile const auto  () { return v; }
+  volatile const auto & () { return (T&&)v; }
+  const volatile auto m13 () { return v; }
+  const volatile auto  () { return v; }
+  const volatile auto & () { return (T&&)v; }
+#ifndef __STRICT_ANSI__
+  __restrict const volatile auto & () { return (T&&)v; }
+  const __restrict auto  () { return v; }
+#endif
+};
+
+S s, u, v;
+
+long
+foo ()
+{
+  return s.m1 () + s.m2 () + s.m3 () + s.m4 () + s.m5 ()
++ s.m6 () + s.m7 () + s.m8 () + s.m9 () + s.m10 ()
++ s.m11 () + s.m12 () + s.m13 () + s.m14 () + s.m15 ()
+#ifndef __STRICT_ANSI__
++ u.m16 () + v.m17 ()
+#endif
++ 0;
+}
+
+int
+main ()
+{
+  return foo ();
+}

Jakub





Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/3/20 9:08 PM, Marek Polacek wrote:

On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote:

On 3/30/20 4:28 PM, Marek Polacek wrote:

Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:

/* ??? Here's to hoping the front end fills in all of the indices,
   so we don't have to figure out what's missing ourselves.  */
gcc_assert (purpose);

The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.  So
fill in the indexes manually, here we have an array, and we can simply
assign indexes starting from 0.

Bootstrapped/regtested on x86_64-linux, ok for trunk?


Shouldn't digest_init fill in the indexes?  In
process_init_constructor_array I see

   if (!ce->index)
 ce->index = size_int (i);


Yes, that works too.  Thus:

Bootstrapped/regtested on x86_64-linux, ok for trunk?

-- >8 --
Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:

   /* ??? Here's to hoping the front end fills in all of the indices,
  so we don't have to figure out what's missing ourselves.  */
   gcc_assert (purpose);

The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.  So
call digest_init to fill in the indexes.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

PR c++/94155 - crash in gimplifier with paren init of aggregates.
* decl.c (check_initializer): Call digest_init.

* g++.dg/cpp2a/paren-init22.C: New test.
---
  gcc/cp/decl.c |  5 +
  gcc/testsuite/g++.dg/cpp2a/paren-init22.C | 15 +++
  2 files changed, 20 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init22.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 69a238997b4..63e7bda09f5 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6754,6 +6754,11 @@ check_initializer (tree decl, tree init, int flags, 
vec **cleanups)
  init = build_constructor_from_list (init_list_type_node, init);
  CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
  CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+ /* The gimplifier expects that the front end fills in all of the
+indices.  Normally, reshape_init_array fills these in, but we
+don't call reshape_init because that does nothing when it gets
+CONSTRUCTOR_IS_PAREN_INIT.  */
+ init = digest_init (type, init, tf_warning_or_error);


But why weren't we already calling digest_init in store_init_value?  Was 
the CONSTRUCTOR making it all the way to gimplification still having 
init_list_type_node?



}
}
else if (TREE_CODE (init) == TREE_LIST
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init22.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init22.C
new file mode 100644
index 000..1b2959e7731
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/paren-init22.C
@@ -0,0 +1,15 @@
+// PR c++/94155 - crash in gimplifier with paren init of aggregates.
+// { dg-do compile { target c++2a } }
+
+struct S { int i, j; };
+
+struct A {
+  S s;
+  constexpr A(S e) : s(e) {}
+};
+
+void
+f()
+{
+  A g[1]({{1, 1}});
+}

base-commit: 0c809f727cd2a6c70c307d9dd53d26dc84bf292a





[RFA] skip gcc.target/arm/div64-unwinding.c on vxworks_kernel targets

2020-04-03 Thread Joel Brobecker
Hello,

This test verifies, by using a weak reference to _Unwind_RaiseException,
that performing division by zero does not cause that symbol to get
indirectly pulled into our closure.

The testing methodology unfortunately does not work on VxWorks targets
when building in kernel mode. This is inherent to how kernel mode
on VxWorks works: The link is only partial and the remaining symbols
which have not been resolved already get automatically resolved by
the VxWorks loader at the moment the module is loaded onto the target,
prior to execution. The resolution includes weak symbols too, which
defeats the purpose of this test.

gcc/testsuite/

* gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets.

Tested by running the test on ARM VxWorks 7 SR0640, both in kernel
mode as well as RTP mode (verifying it only gets disabled when in
kernel mode). Also run on ARM ELF to verify that this still runs on
non-VxWorks targets.

OK to push to master?

Thank you!
-- 
Joel

---
 gcc/testsuite/gcc.target/arm/div64-unwinding.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/arm/div64-unwinding.c 
b/gcc/testsuite/gcc.target/arm/div64-unwinding.c
index 09442811fb6..c10ac248354 100644
--- a/gcc/testsuite/gcc.target/arm/div64-unwinding.c
+++ b/gcc/testsuite/gcc.target/arm/div64-unwinding.c
@@ -1,6 +1,7 @@
 /* Performing a 64-bit division should not pull in the unwinder.  */
 
 /* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
+/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
 /* { dg-options "-O0" } */
 
 #include 
-- 
2.17.1



Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

2020-04-03 Thread Marek Polacek via Gcc-patches
On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote:
> On 3/30/20 4:28 PM, Marek Polacek wrote:
> > Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
> > expect null indexes for a constructor:
> > 
> >/* ??? Here's to hoping the front end fills in all of the indices,
> >   so we don't have to figure out what's missing ourselves.  */
> >gcc_assert (purpose);
> > 
> > The indexes weren't filled because we never called reshape_init: for
> > a constructor that represents parenthesized initialization of an
> > aggregate we don't allow brace elision or designated initializers.  So
> > fill in the indexes manually, here we have an array, and we can simply
> > assign indexes starting from 0.
> > 
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> Shouldn't digest_init fill in the indexes?  In
> process_init_constructor_array I see
> 
>   if (!ce->index)
> ce->index = size_int (i);

Yes, that works too.  Thus:

Bootstrapped/regtested on x86_64-linux, ok for trunk?

-- >8 --
Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:

  /* ??? Here's to hoping the front end fills in all of the indices,
 so we don't have to figure out what's missing ourselves.  */
  gcc_assert (purpose);

The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.  So
call digest_init to fill in the indexes.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

PR c++/94155 - crash in gimplifier with paren init of aggregates.
* decl.c (check_initializer): Call digest_init.

* g++.dg/cpp2a/paren-init22.C: New test.
---
 gcc/cp/decl.c |  5 +
 gcc/testsuite/g++.dg/cpp2a/paren-init22.C | 15 +++
 2 files changed, 20 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init22.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 69a238997b4..63e7bda09f5 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6754,6 +6754,11 @@ check_initializer (tree decl, tree init, int flags, 
vec **cleanups)
  init = build_constructor_from_list (init_list_type_node, init);
  CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
  CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+ /* The gimplifier expects that the front end fills in all of the
+indices.  Normally, reshape_init_array fills these in, but we
+don't call reshape_init because that does nothing when it gets
+CONSTRUCTOR_IS_PAREN_INIT.  */
+ init = digest_init (type, init, tf_warning_or_error);
}
}
   else if (TREE_CODE (init) == TREE_LIST
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init22.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init22.C
new file mode 100644
index 000..1b2959e7731
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/paren-init22.C
@@ -0,0 +1,15 @@
+// PR c++/94155 - crash in gimplifier with paren init of aggregates.
+// { dg-do compile { target c++2a } }
+
+struct S { int i, j; };
+
+struct A {
+  S s;
+  constexpr A(S e) : s(e) {}
+};
+
+void
+f()
+{
+  A g[1]({{1, 1}});
+}

base-commit: 0c809f727cd2a6c70c307d9dd53d26dc84bf292a
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA



Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread Alan Modra via Gcc-patches
On Fri, Apr 03, 2020 at 04:11:32PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote:
> > Segher probably meant the part I'm working on and haven't posted yet,
> > fixing lots of problems with rs6000_rtx_costs.
> 
> I meant PR94393 in fact, but yeah, this is connected *everywhere* :-)
> 
> > One of the improvements
> > I'm aiming for is that we should be able to emit code that loads
> > constants from memory without following optimisation passes converting
> > the loads from memory to those long sequences of dependent instructions.
> 
> Yeah.  Looking forward to it :-)

I have a series of small patches already, the most significant so far
being the one that adds the following comment to rs6000_rtx_costs:

  "Calls from places like optabs.c:avoid_expensive_constant will come
   here with OUTER_CODE set to an operation such as AND with X being a
   CONST_INT or other CONSTANT_P type.  This will be compared against
   set_src_cost, where we'll come here with OUTER_CODE as SET and X
   the same constant.

   Calls from places like default_noce_conversion_profitable_p will
   come here via seq_cost and pass the pattern of a SET insn in X.
   The SET isn't handled here so *TOTAL will remain as
   COSTS_N_INSNS(1) multiplied by the number of words being set.
   Presuming the insn is valid and set_dest a reg, rs6000_rtx_costs
   will next see the set_src.  Continuing the example of an AND, this
   might be an AND of two other regs.  This AND should cost zero here
   since the insn cost has already been counted.  The overall cost
   value should be comparable to rs6000_insn_cost."

It pays to figure out what you need to do before doing anything.  :-)

Those two paragraphs will result in quite a few changes.  The first
one means that, for example, the rs6000_is_valid_and_mask test belongs
under case CONST_INT as
  || (outer_code == AND
  && rs6000_is_valid_and_mask (x, mode))
not under case AND.

The second paragraph says we are costing practically all operations
too highly.

I'm still in analysis mode, worried about whether gcc generates deep
rtl expressions to pass to rtx_cost.  I have a vague recollection of
seeing that years ago, but it looks like most places with anything
complex generate a sequence of insns and cost the sequence.  If we do
have expressions like (set (reg1) (and (plus (reg2) cst1) cst2)) then
rs6000_rtx_cost should recognise that AND as costing an extra insn.

-- 
Alan Modra
Australia Development Lab, IBM


[committed] Fix xstormy16 fallout from Jakub's cselib changes

2020-04-03 Thread Jeff Law via Gcc-patches

This fixes more fallout from Jakub's cselib changes.  This shows up as an ICE
building stdarg-3 from the testsuite after Jakub's changes.  However, a reduced
testcase will fail miserably all the way back to gcc-7 (as far back as I 
tested).



The xstormy port only allows a subset of the registers to be used in memory
operands.  Additionally it allows auto-increment addressing modes.  The
combination of the two creates an interesting problem with reloading.



So you might have something like

(set (pseudo1) (mem (post_inc (pseudo2)))

Now assume that pseudo1 gets a hard reg, a nice convenient one like r2, but 
sadly
pseudo2 gets no hard reg and is on the stack.  You end up with something like
this during reload

(set (reg 2) (mem (post_inc (mem (plus (sp) (offset))

Uh-oh.  Reload knows how to deal with this most of the time :-) Assume that we
get r10 as our reload register.  Reload will generate something like this:

(set (reg 10) (mem (plus (sp) (offset// Load pseudo2 from stack
(set (reg 10) (plus (reg 10) (const_int 2))) // autoinc
(set (mem (plus (sp) (offset)) (reg10))  // Store autoinc'd value back
(set (reg 10) (plus (reg 10) (const_int -2)))// Undo autoinc
(set (reg 2) (mem (reg 10))) // And set the actual output



But wait, I mentioned the port limits what registers can be used in memory
references.  The code above isn't valid because r10 can't be the destination of 
a
load from memory or the source of a store to memory and we'll ICE.

It took a while to get my bearings.  I haven't had to think about reload in a
long time and after several false starts I realized the problem was the reload
register selection, not secondary reloads.  Get the right kind of reload 
register
and the right things will just happen.

The preferred_reload_class does get called on the (post_inc ...) mess via
find_reloads_address_1.  ie, given:

(insn 34 171 35 2 (set (reg:HI 2 r2 [orig:37 a3+2 ] [37])
(mem/c:HI (post_inc:HI (reg/f:HI 89)) [1 a3+2 S2 A16])) "testcase.c":8:6
6 {movhi_internal}
 (expr_list:REG_INC (reg/f:HI 89)
(nil)))

We'll call preferred_reload_class with the post_inc expression where the pseudo
has been replaced with its equivalent memory:

(post_inc:HI (mem/c:HI (plus:HI (reg/f:HI 15 sp)
(const_int -34 [0xffde])) [3 %sfp+44 S2 A16]))

So the fix here is to realize that reloading an address of that from must be 
done
with one of the registers that is suitable for memory operands.

I expected this to fix several other long standing ICEs on the port which
(without digging) seemed like they were likely related.  Sadly, it just fixed 
the
regression.

Anyway, I'll be committing this to the trunk momentarily.

Jeff
commit 7f26e60c2600f0a676fc9370390ebf0a3c78f31c
Author: Jeff Law 
Date:   Fri Apr 3 17:47:18 2020 -0600

Fix stdarg-3 regression on xstormy16 port

PR rtl-optimization/92264
* config/stormy16/stormy16.c (xstormy16_preferred_reload_class): 
Handle
reloading of auto-increment addressing modes.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6317e385cac..25d1c5d1c38 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-03  Jeff Law  
+
+   PR rtl-optimization/92264
+   * config/stormy16/stormy16.c (xstormy16_preferred_reload_class): Handle
+   reloading of auto-increment addressing modes.
+
 2020-04-03  H.J. Lu  
 
PR target/94467
diff --git a/gcc/config/stormy16/stormy16.c b/gcc/config/stormy16/stormy16.c
index 55fe82954c1..2141531e262 100644
--- a/gcc/config/stormy16/stormy16.c
+++ b/gcc/config/stormy16/stormy16.c
@@ -497,7 +497,17 @@ xstormy16_secondary_reload_class (enum reg_class rclass,
 static reg_class_t
 xstormy16_preferred_reload_class (rtx x, reg_class_t rclass)
 {
-  if (rclass == GENERAL_REGS && MEM_P (x))
+  /* Only the first eight registers can be moved to/from memory.
+ So those prefer EIGHT_REGS.
+
+ Similarly reloading an auto-increment address is going to
+ require loads and stores, so we must use EIGHT_REGS for those
+ too.  */
+  if (rclass == GENERAL_REGS
+  && (MEM_P (x)
+ || GET_CODE (x) == POST_INC
+ || GET_CODE (x) == PRE_DEC
+ || GET_CODE (x) == PRE_MODIFY))
 return EIGHT_REGS;
 
   return rclass;


[PATCH] gcc/gcc.c: add outfiles spec

2020-04-03 Thread Rasmus Villemoes
Commit 0b7fb27b698d (Fix and document -r option) broke building of
VxWorks modules, at least for our version of VxWorks. A VxWorks module
is a relocatable ELF file - the final link is done when the file is
linked in to the running kernel. So building with -r is
necessary. However, the module also needs to be wrapped in
crtbegin.o/crtend.o in order to have the exception frame info
registered with the run-time.

We used to achieve that with a custom spec file that specified
crtbegin.o and crtend.o as start/endfile, but after the above commit,
%S and %E no longer get substituted.

In order to allow custom spec files to add arbitrary objects at the
beginning/end, add a level of indirection that puts "%o" in a new
outfiles spec - then the custom spec file can override that with the

%rename outfiles old_outfiles

*outfiles:
  ...

idiom.

Of course, the custom spec file could also override all of the
link_command, but that's a lot of logic to copy-paste and keep in
sync.

gcc/ChangeLog:

2020-04-04  Rasmus Villemoes  

* gcc.c (OUTFILES_SPEC): New spec, hook for wrapping or
  overriding %o.

---
I'm not quite up to speed on how the gcc repo works after the switch
to git. Please advise.

 gcc/gcc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 9f790db0daf..7ea7e2a3ae0 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -804,6 +804,10 @@ proper position among the other output files.  */
 #define ENDFILE_SPEC ""
 #endif
 
+#ifndef OUTFILES_SPEC
+#define OUTFILES_SPEC "%o"
+#endif
+
 #ifndef LINKER_NAME
 #define LINKER_NAME "collect2"
 #endif
@@ -1042,7 +1046,7 @@ proper position among the other output files.  */
"%X %{o*} %{e*} %{N} %{n} %{r}\
 %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!r:%{!nostartfiles:%S}}} \
 %{static|no-pie|static-pie:} %@{L*} %(mfwrap) %(link_libgcc) " \
-VTABLE_VERIFICATION_SPEC " " SANITIZER_EARLY_SPEC " %o "" \
+VTABLE_VERIFICATION_SPEC " " SANITIZER_EARLY_SPEC " %(outfiles) "" \
 %{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1):\
%:include(libgomp.spec)%(link_gomp)}\
 %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
@@ -1087,6 +1091,7 @@ static const char *link_gomp_spec = "";
 static const char *libgcc_spec = LIBGCC_SPEC;
 static const char *endfile_spec = ENDFILE_SPEC;
 static const char *startfile_spec = STARTFILE_SPEC;
+static const char *outfiles_spec = OUTFILES_SPEC;
 static const char *linker_name_spec = LINKER_NAME;
 static const char *linker_plugin_file_spec = "";
 static const char *lto_wrapper_spec = "";
@@ -1596,6 +1601,7 @@ static struct spec_list static_specs[] =
   INIT_STATIC_SPEC ("linker_plugin_file",  _plugin_file_spec),
   INIT_STATIC_SPEC ("lto_wrapper", _wrapper_spec),
   INIT_STATIC_SPEC ("lto_gcc", _gcc_spec),
+  INIT_STATIC_SPEC ("outfiles",_spec),
   INIT_STATIC_SPEC ("post_link",   _link_spec),
   INIT_STATIC_SPEC ("link_libgcc", _libgcc_spec),
   INIT_STATIC_SPEC ("md_exec_prefix",  _exec_prefix),
-- 
2.23.0



[PATCH v4 5/5] libgomp/test: Remove a build sysroot fix regression

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation 
for build sysroot") that caused a regression in some standalone test 
environments where testsuite/libgomp-test-support.exp is used, but the 
compiler is expected to be determined by `[find_gcc]', and set the 
GCC_UNDER_TEST TCL variable in testsuite/libgomp-site-extra.exp instead.

libgomp/
* configure.ac: Add testsuite/libgomp-site-extra.exp to output 
files.
* configure: Regenerate.
* testsuite/libgomp-site-extra.exp.in: New file.
* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Remove 
variable.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
variable.
* testsuite/Makefile.in: Regenerate.
---
No changes from v3.

Changes from v2:

- Do not use `--tool_exec' with AM_RUNTESTFLAGS.

- Move the definition of GCC_UNDER_TEST from 
  testsuite/libgomp-test-support.exp to 
  testsuite/libgomp-site-extra.exp.

Applies on top of v1.
---
 libgomp/configure |3 +++
 libgomp/configure.ac  |1 +
 libgomp/testsuite/Makefile.am |2 ++
 libgomp/testsuite/Makefile.in |6 +-
 libgomp/testsuite/libgomp-site-extra.exp.in   |1 +
 libgomp/testsuite/libgomp-test-support.exp.in |2 --
 6 files changed, 12 insertions(+), 3 deletions(-)

gcc-test-libgomp-site-extra.diff
Index: gcc/libgomp/configure
===
--- gcc.orig/libgomp/configure
+++ gcc/libgomp/configure
@@ -17047,6 +17047,8 @@ ac_config_files="$ac_config_files Makefi
 
 ac_config_files="$ac_config_files 
testsuite/libgomp-test-support.pt.exp:testsuite/libgomp-test-support.exp.in"
 
+ac_config_files="$ac_config_files testsuite/libgomp-site-extra.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -18200,6 +18202,7 @@ do
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
 "libgomp.spec") CONFIG_FILES="$CONFIG_FILES libgomp.spec" ;;
 "testsuite/libgomp-test-support.pt.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgomp-test-support.pt.exp:testsuite/libgomp-test-support.exp.in" ;;
+"testsuite/libgomp-site-extra.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgomp-site-extra.exp" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
Index: gcc/libgomp/configure.ac
===
--- gcc.orig/libgomp/configure.ac
+++ gcc/libgomp/configure.ac
@@ -436,4 +436,5 @@ GCC_BASE_VER
 AC_CONFIG_FILES(omp.h omp_lib.h omp_lib.f90 libgomp_f.h)
 AC_CONFIG_FILES(Makefile testsuite/Makefile libgomp.spec)
 
AC_CONFIG_FILES([testsuite/libgomp-test-support.pt.exp:testsuite/libgomp-test-support.exp.in])
+AC_CONFIG_FILES([testsuite/libgomp-site-extra.exp])
 AC_OUTPUT
Index: gcc/libgomp/testsuite/Makefile.am
===
--- gcc.orig/libgomp/testsuite/Makefile.am
+++ gcc/libgomp/testsuite/Makefile.am
@@ -12,6 +12,8 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
 
+EXTRA_DEJAGNU_SITE_CONFIG = libgomp-site-extra.exp
+
 # Instead of directly in ../testsuite/libgomp-test-support.exp.in, the
 # following variables have to be "routed through" this Makefile, for expansion
 # of the several (Makefile) variables used therein.
Index: gcc/libgomp/testsuite/Makefile.in
===
--- gcc.orig/libgomp/testsuite/Makefile.in
+++ gcc/libgomp/testsuite/Makefile.in
@@ -111,7 +111,8 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES = libgomp-test-support.pt.exp
+CONFIG_CLEAN_FILES = libgomp-test-support.pt.exp \
+   libgomp-site-extra.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -310,6 +311,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
+EXTRA_DEJAGNU_SITE_CONFIG = libgomp-site-extra.exp
 all: all-am
 
 .SUFFIXES:
@@ -344,6 +346,8 @@ $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(
 $(am__aclocal_m4_deps):
 libgomp-test-support.pt.exp: $(top_builddir)/config.status 
$(srcdir)/libgomp-test-support.exp.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
+libgomp-site-extra.exp: $(top_builddir)/config.status 
$(srcdir)/libgomp-site-extra.exp.in
+   cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 mostlyclean-libtool:
-rm -f *.lo
Index: 

[PATCH v4 GCC 3/5] libffi/test: Make `libffi-init' use $CC_FOR_TARGET

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Update code in `libffi-init' to use $CC_FOR_TARGET in determining the 
value of $ld_library_path, as using a different compiler location from 
one actually used in testing may have odd consequences.

As this obviously loses the setting of $gccdir provide a replacement way 
to determine the directory if feasible, however prefer the location of 
shared libgcc over static libgcc.  This helps in configurations where 
shared libgcc is, unlike libgcc, a location that is not specific to the 
compiler version, a common scenario.  It does not address the scenario 
however where there is a shared libgcc symlink installed pointing to the 
actual run-time library installed elsewhere; this would have to be dealt 
with in a board description file specific to the installation.

Use `remote_exec host' rather than `exec' to invoke the compiler so as 
to support remote configurations and also avoid the latter procedure's 
path length limitation that prevents execution in some actual scenarios.

As using `remote_exec host' precludes the use of our existing file name 
globbing to examine directory contents reuse, with minor modifications 
needed to adjust to our structure, the piece I previously contributed to 
GCC with commit d42b84f427e4 ("testsuite: Fix run-time tracking down 
of `libgcc_s'").

libffi/
* testsuite/lib/libffi.exp (libffi-init): Use CC_FOR_TARGET.
Update the determination of `ld_library_path' accordingly.
---
This is a backport of combined upstream libffi changes as recorded here: 
 and 
here:  
(there's no point to introduce indentation breakage only to fix it with 
the next change).

New change in v4.
---
 libffi/testsuite/lib/libffi.exp |   72 ++--
 1 file changed, 54 insertions(+), 18 deletions(-)

gcc-test-libffi-init-compiler.diff
Index: gcc/libffi/testsuite/lib/libffi.exp
===
--- gcc.orig/libffi/testsuite/lib/libffi.exp
+++ gcc/libffi/testsuite/lib/libffi.exp
@@ -99,7 +99,7 @@ proc libffi-init { args } {
 global blddirffi
 global objdir
 global blddircxx
-global TOOL_OPTIONS
+global CC_FOR_TARGET
 global tool
 global libffi_include
 global libffi_link_flags
@@ -114,26 +114,62 @@ proc libffi-init { args } {
 
 set compiler_vendor "gnu"
 
-set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
-if {$gccdir != ""} {
-   set gccdir [file dirname $gccdir]
-}
-verbose "gccdir $gccdir"
+if { [string match $compiler_vendor "gnu"] } {
+   if [info exists CC_FOR_TARGET] then {
+   set compiler "$CC_FOR_TARGET"
+   set libgcc_a_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc.a"]
+   if { [lindex $libgcc_a_x 0] == 0 } {
+   set gccdir [file dirname [lindex $libgcc_a_x 1]]
+   } else {
+   set gccdir ""
+   }
+   } else {
+   set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
+   if {$gccdir != ""} {
+   set gccdir [file dirname $gccdir]
+   }
+   set compiler "${gccdir}/xgcc"
+   }
+   verbose "gccdir $gccdir"
 
-set ld_library_path "."
-append ld_library_path ":${gccdir}"
+   set shlib_ext [get_shlib_extension]
+   set libgcc_s_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc_s.${shlib_ext}"]
+   if { [lindex $libgcc_s_x 0] == 0 } {
+   set libgcc_dir [file dirname [lindex $libgcc_s_x 1]]
+   } else {
+   set libgcc_dir $gccdir
+   }
+   verbose "libgcc_dir $libgcc_dir"
 
-set compiler "${gccdir}/xgcc"
-if { [is_remote host] == 0 && [which $compiler] != 0 } {
-   foreach i "[exec $compiler --print-multi-lib]" {
-   set mldir ""
-   regexp -- "\[a-z0-9=_/\.-\]*;" $i mldir
-   set mldir [string trimright $mldir "\;@"]
-   if { "$mldir" == "." } {
-   continue
+   set ld_library_path "."
+   append ld_library_path ":${gccdir}"
+
+   set multi_dir_x [remote_exec host "$compiler" "-print-multi-directory"]
+   set multi_lib_x [remote_exec host "$compiler" "-print-multi-lib"]
+   if { [lindex $multi_dir_x 0] == 0 && [lindex $multi_lib_x 0] == 0 } {
+   set multi_dir [string trim [lindex $multi_dir_x 1]]
+   set multi_lib [string trim [lindex $multi_lib_x 1]]
+   if { "$multi_dir" == "." } {
+   set multi_root "$libgcc_dir"
+   } else {
+   set multi_match [string last "/$multi_dir" "$libgcc_dir"]
+   if { "$multi_match" >= 0 } {
+   set multi_root [string range "$libgcc_dir" \
+   0 [expr $multi_match - 1]]
+   } else {
+   set multi_lib ""
+ 

[PATCH v4 4/5] libgo/test: Complement compilation fix for build sysroot

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler 
when using build sysroot") and move testsuite/libgo-test-support.exp.in 
to testsuite/libgo-site-extra.exp.in.  Update testsuite/lib/libgo.exp to 
handle the `--tool_exec' option to `runtest' as with other top-level GCC 
target libraries, by using the TOOL_EXECUTABLE TCL variable.

libgo/
* configure.ac: Produce testsuite/libgo-site-extra.exp rather 
than testsuite/libgo-test-support.exp.
* configure: Regenerate.
* testsuite/libgo-test-support.exp.in: Rename file to...
* testsuite/libgo-site-extra.exp.in: ... this.
* testsuite/Makefile.am: Use libgo-site-extra.exp rather than 
libgo-test-support.exp.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgo.exp: Handle TOOL_EXECUTABLE.
---
No changes from v3.

Changes from v2:

- Rename testsuite/libgo-test-support.exp.in to 
  testsuite/libgo-site-extra.exp.in.

Applies on top of v1.
---
 libgo/configure   |4 ++--
 libgo/configure.ac|2 +-
 libgo/testsuite/Makefile.am   |2 +-
 libgo/testsuite/Makefile.in   |6 +++---
 libgo/testsuite/lib/libgo.exp |   12 
 libgo/testsuite/libgo-site-extra.exp.in   |   17 +
 libgo/testsuite/libgo-test-support.exp.in |   17 -
 7 files changed, 32 insertions(+), 28 deletions(-)

gcc-test-libgo-site-extra.diff
Index: gcc/libgo/configure
===
--- gcc.orig/libgo/configure
+++ gcc/libgo/configure
@@ -15893,7 +15893,7 @@ else
   multilib_arg=
 fi
 
-ac_config_files="$ac_config_files Makefile testsuite/Makefile 
testsuite/libgo-test-support.exp"
+ac_config_files="$ac_config_files Makefile testsuite/Makefile 
testsuite/libgo-site-extra.exp"
 
 
 ac_config_commands="$ac_config_commands default"
@@ -17074,7 +17074,7 @@ do
 "libtool") CONFIG_COMMANDS="$CONFIG_COMMANDS libtool" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
-"testsuite/libgo-test-support.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgo-test-support.exp" ;;
+"testsuite/libgo-site-extra.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgo-site-extra.exp" ;;
 "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
Index: gcc/libgo/configure.ac
===
--- gcc.orig/libgo/configure.ac
+++ gcc/libgo/configure.ac
@@ -895,7 +895,7 @@ else
   multilib_arg=
 fi
 
-AC_CONFIG_FILES(Makefile testsuite/Makefile testsuite/libgo-test-support.exp)
+AC_CONFIG_FILES(Makefile testsuite/Makefile testsuite/libgo-site-extra.exp)
 
 AC_CONFIG_COMMANDS([default],
 [if test -n "$CONFIG_FILES"; then
Index: gcc/libgo/testsuite/Makefile.am
===
--- gcc.orig/libgo/testsuite/Makefile.am
+++ gcc/libgo/testsuite/Makefile.am
@@ -11,7 +11,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
-EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
+EXTRA_DEJAGNU_SITE_CONFIG = libgo-site-extra.exp
 
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
Index: gcc/libgo/testsuite/Makefile.in
===
--- gcc.orig/libgo/testsuite/Makefile.in
+++ gcc/libgo/testsuite/Makefile.in
@@ -107,7 +107,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES = libgo-test-support.exp
+CONFIG_CLEAN_FILES = libgo-site-extra.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -300,7 +300,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
-EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
+EXTRA_DEJAGNU_SITE_CONFIG = libgo-site-extra.exp
 
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
@@ -340,7 +340,7 @@ $(top_srcdir)/configure: @MAINTAINER_MOD
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
-libgo-test-support.exp: $(top_builddir)/config.status 
$(srcdir)/libgo-test-support.exp.in
+libgo-site-extra.exp: $(top_builddir)/config.status 
$(srcdir)/libgo-site-extra.exp.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 

[PATCH v4 GCC 2/5] libffi/test: Fix compilation for build sysroot

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Fix a problem with the libffi testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
inability to actually choose any compiler at all in a cross-compilation 
configuration.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by 
autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
default_target_compile: No compiler to compile with
UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation 
failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libffi Summary ===

# of unexpected failures708
# of unresolved testcases   708
# of unsupported tests  30

to:

=== libffi Summary ===

# of expected passes1934
# of unsupported tests  28

libffi/
* configure.ac: Add testsuite/local.exp to output files.
* configure: Regenerate.
* testsuite/local.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
This is a backport of upstream libffi change as recorded here: 
.

New change in v4.
---
 libffi/configure  |3 ++-
 libffi/configure.ac   |2 +-
 libffi/testsuite/Makefile.am  |2 ++
 libffi/testsuite/Makefile.in  |5 -
 libffi/testsuite/local.exp.in |2 ++
 5 files changed, 11 insertions(+), 3 deletions(-)

gcc-test-libffi-cc-for-target-template.diff
Index: gcc/libffi/configure
===
--- gcc.orig/libffi/configure
+++ gcc/libffi/configure
@@ -16662,7 +16662,7 @@ ac_config_commands="$ac_config_commands
 ac_config_links="$ac_config_links 
include/ffitarget.h:src/$TARGETDIR/ffitarget.h"
 
 
-ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile 
testsuite/Makefile man/Makefile libffi.pc"
+ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile 
testsuite/Makefile testsuite/local.exp man/Makefile libffi.pc"
 
 
 cat >confcache <<\_ACEOF
@@ -17829,6 +17829,7 @@ do
 "include/ffi.h") CONFIG_FILES="$CONFIG_FILES include/ffi.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/local.exp") CONFIG_FILES="$CONFIG_FILES testsuite/local.exp" ;;
 "man/Makefile") CONFIG_FILES="$CONFIG_FILES man/Makefile" ;;
 "libffi.pc") CONFIG_FILES="$CONFIG_FILES libffi.pc" ;;
 
Index: gcc/libffi/configure.ac
===
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -377,6 +377,6 @@ test -d src/$TARGETDIR || mkdir src/$TAR
 
 AC_CONFIG_LINKS(include/ffitarget.h:src/$TARGETDIR/ffitarget.h)
 
-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile 
man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile 
testsuite/local.exp man/Makefile libffi.pc)
 
 AC_OUTPUT
Index: gcc/libffi/testsuite/Makefile.am
===
--- gcc.orig/libffi/testsuite/Makefile.am
+++ gcc/libffi/testsuite/Makefile.am
@@ -13,6 +13,8 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 
 AM_RUNTESTFLAGS =
 
+EXTRA_DEJAGNU_SITE_CONFIG = local.exp
+
 CLEANFILES = *.exe core* *.log *.sum
 
 EXTRA_DIST = config/default.exp libffi.call/cls_19byte.c   \
Index: gcc/libffi/testsuite/Makefile.in
===
--- gcc.orig/libffi/testsuite/Makefile.in
+++ gcc/libffi/testsuite/Makefile.in
@@ -106,7 +106,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/fficonfig.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = local.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -279,6 +279,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = local.exp
 CLEANFILES = *.exe core* *.log *.sum
 EXTRA_DIST = config/default.exp libffi.call/cls_19byte.c   \
 libffi.call/cls_align_longdouble_split.c   \
@@ -390,6 +391,8 @@ 

[PATCH v4 1/5] libatomic/test: Fix compilation for build sysroot

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Fix a problem with the libatomic testsuite using a method to determine 
the compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' 
configuration option has been used to build the compiler resulting in 
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm

UNRESOLVED: libatomic.c/atomic-compare-exchange-1.c compilation failed to 
produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libatomic Summary ===

# of unexpected failures27
# of unresolved testcases   27

to:

=== libatomic Summary ===

# of expected passes54

libatomic/
* configure.ac: Add testsuite/libatomic-site-extra.exp to output 
files.
* configure: Regenerate.
* libatomic/testsuite/libatomic-site-extra.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
No change from v3.

Changes from v2:

- Revert to v1.

- Rename testsuite/libatomic-test-support.exp.in to 
  testsuite/libatomic-site-extra.exp.in.

Changes from v1:

- Remove testsuite/libatomic-test-support.exp.in and the associated
  changes.

- Pass $(CC) via `--tool_exec' in $(AM_RUNTESTFLAGS).
---
 libatomic/configure |3 +++
 libatomic/configure.ac  |1 +
 libatomic/testsuite/Makefile.am |2 ++
 libatomic/testsuite/Makefile.in |5 -
 libatomic/testsuite/libatomic-site-extra.exp.in |1 +
 5 files changed, 11 insertions(+), 1 deletion(-)

gcc-test-libatomic-gcc-under-test.diff
Index: gcc/libatomic/configure
===
--- gcc.orig/libatomic/configure
+++ gcc/libatomic/configure
@@ -15728,6 +15728,8 @@ fi
 
 ac_config_files="$ac_config_files Makefile testsuite/Makefile"
 
+ac_config_files="$ac_config_files testsuite/libatomic-site-extra.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -16799,6 +16801,7 @@ do
 "gstdint.h") CONFIG_COMMANDS="$CONFIG_COMMANDS gstdint.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/libatomic-site-extra.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libatomic-site-extra.exp" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
Index: gcc/libatomic/configure.ac
===
--- gcc.orig/libatomic/configure.ac
+++ gcc/libatomic/configure.ac
@@ -288,4 +288,5 @@ else
 fi
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile)
+AC_CONFIG_FILES(testsuite/libatomic-site-extra.exp)
 AC_OUTPUT
Index: gcc/libatomic/testsuite/Makefile.am
===
--- gcc.orig/libatomic/testsuite/Makefile.am
+++ gcc/libatomic/testsuite/Makefile.am
@@ -11,3 +11,5 @@ EXPECT = $(shell if test -f $(top_buildd
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+
+EXTRA_DEJAGNU_SITE_CONFIG = libatomic-site-extra.exp
Index: gcc/libatomic/testsuite/Makefile.in
===
--- gcc.orig/libatomic/testsuite/Makefile.in
+++ gcc/libatomic/testsuite/Makefile.in
@@ -109,7 +109,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/auto-config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libatomic-site-extra.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -278,6 +278,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo 

[PATCH v4 0/5] Fix library testsuite compilation for build sysroot

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Hi,

 This is v4 of patch series, originally posted here:






v2 posted here:






and v3 posted here:






meant to address a problem with the testsuite compiler being set up across 
libatomic, libffi, libgo, libgomp with no correlation whatsoever to the 
target compiler being used in GCC compilation.  Consequently there in no 
arrangement made to set up the compilation sysroot according to the build 
sysroot specified for GCC compilation, causing a catastrophic failure 
across the testsuites affected from the inability to link executables.

 In the course of discussion it has been determined it might be the best 
if we sync with libffi rather than providing our replacement solution, as 
the upstream version has it addressed, although in a slightly messy way.  
I have therefore decided to clean it up with upstream libffi and propose a 
corresponding backport of the change to be included with our version.  
This has resulted in two patches actually, replacing 2/4 from the original 
series.  The remaining changes are the same as in v3, however Chung-Lin 
has since confirmed the libgomp change proposed here has addressed issues 
with testing in his environment (thank you, Chung-Lin!).

 Verified with a cross-compiler configured for the `riscv-linux-gnu' 
target and the `x86_64-linux-gnu' host and using RISC-V/Linux QEMU in the 
user emulation mode as the target board.  Also no change in results with 
`x86_64-linux-gnu' native regression testing.

 See individual change descriptions for details.

 I'm assuming Ian will take care of the 4/5 libgo change (Ian, it's up to 
you if you want to have it or not).

 Any objections about 1/5 previously approved by Jeff, and OK to apply 2/5 
and 3/5 (if the corresponding changes have been accepted into upstream 
libffi), as well as 5/5 to the GCC repo?

  Maciej



Re: [PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

2020-04-03 Thread Hannes Domani via Gcc-patches
 Am Samstag, 4. April 2020, 00:47:27 MESZ hat Jakub Jelinek via Gcc-patches 
 Folgendes geschrieben:

> Hi!
>
> On the following testcase, in gdb ptype S::m1 prints long as return
> type, but all the other methods show void instead.
> PR53756 added code to add_type_attribute if the return type is
> auto/decltype(auto), but we actually should look through references,
> pointers and qualifiers.
> Haven't included there DW_TAG_atomic_type, because I think at least ATM
> one can't use that in C++.  Not sure about DW_TAG_array_type or what else
> could be deduced.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-04-04  Domani Hannes  
> Jakub Jelinek  

Minor hiccup from my side, my name should be written as Hannes Domani.

I think when I registered the bugzilla account, I wasn't aware yet that
it should be family name last, I've fixed that now.


Hannes


[PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Update code in `libffi-init' to use $CC_FOR_TARGET in determining the 
value of $ld_library_path, as using a different compiler location from 
one actually used in testing may have odd consequences.

As this obviously loses the setting of $gccdir provide a replacement way 
to determine the directory if feasible, however prefer the location of 
shared libgcc over static libgcc.  This helps in configurations where 
shared libgcc is, unlike libgcc, a location that is not specific to the 
compiler version, a common scenario.  It does not address the scenario 
however where there is a shared libgcc symlink installed pointing to the 
actual run-time library installed elsewhere; this would have to be dealt 
with in a board description file specific to the installation.

Use `remote_exec host' rather than `exec' to invoke the compiler so as 
to support remote configurations and also avoid the latter procedure's 
path length limitation that prevents execution in some actual scenarios.

As using `remote_exec host' precludes the use of our existing file name 
globbing to examine directory contents, reuse, with minor modifications 
needed to adjust to our structure, the piece I previously contributed to 
GCC with commit d42b84f427e4 ("testsuite: Fix run-time tracking down 
of `libgcc_s'").
---
Hi,

 This has its limitation in that it still doesn't default to the same 
compiler as `target_compile' (`default_target_compile') from target.exp in 
DejaGNU does, but I believe it is a step in the right direction.  That 
will only affect standalone (e.g. installed) testing iff $CC_FOR_TARGET 
hasn't been set.

 Also for C++ compilation our carefully crafted $ld_library_path is 
unfortunately overridden by `g++_link_flags' from libgloss.exp in DejaGNU 
called in `default_target_compile'.  This actually does cause test 
failures in my `riscv64-linux-gnu' cross-compilation setup:

FAIL: libffi.closures/unwindtest.cc -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.closures/unwindtest.cc -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -Wno-psabi -O0 execution 
test
FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -Wno-psabi -O2 execution 
test

and I am currently not sure how to best address it, i.e. whether to change
DejaGNU's `g++_link_flags' or to take advantage of a TCL's feature and 
provide our own copy of the procedure.  Something to consider sometime.

 NB I chose not to correct obvious indentation issues with lines not 
touched by this change so as not to obfuscate the patch unnecessarily.  A 
complementing formatting change follows.

  Maciej
---
 testsuite/lib/libffi.exp |   68 +++
 1 file changed, 51 insertions(+), 17 deletions(-)

Index: libffi/testsuite/lib/libffi.exp
===
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -272,7 +272,7 @@ proc libffi-init { args } {
 global srcdir
 global blddirffi
 global objdir
-global TOOL_OPTIONS
+global CC_FOR_TARGET
 global tool
 global libffi_include
 global libffi_link_flags
@@ -287,29 +287,63 @@ proc libffi-init { args } {
 verbose "libffi $blddirffi"
 
 if { [string match $compiler_vendor "gnu"] } {
-set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
-if {$gccdir != ""} {
-   set gccdir [file dirname $gccdir]
-}
+   if [info exists CC_FOR_TARGET] then {
+   set compiler "$CC_FOR_TARGET"
+   set libgcc_a_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc.a"]
+   if { [lindex $libgcc_a_x 0] == 0 } {
+   set gccdir [file dirname [lindex $libgcc_a_x 1]]
+   } else {
+   set gccdir ""
+   }
+   } else {
+   set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
+   if {$gccdir != ""} {
+   set gccdir [file dirname $gccdir]
+   }
+   set compiler "${gccdir}/xgcc"
+   }
 verbose "gccdir $gccdir"
 
+   set shlib_ext [get_shlib_extension]
+   set libgcc_s_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc_s.${shlib_ext}"]
+   if { [lindex $libgcc_s_x 0] == 0 } {
+   set libgcc_dir [file dirname [lindex $libgcc_s_x 1]]
+   } else {
+   set libgcc_dir $gccdir
+   }
+   verbose "libgcc_dir $libgcc_dir"
+
 set ld_library_path "."
 append ld_library_path ":${gccdir}"
 
-set compiler "${gccdir}/xgcc"
-if { [is_remote host] == 0 && [which $compiler] != 0 } {
-   foreach i "[exec $compiler --print-multi-lib]" {
-   set mldir ""
-   regexp -- "\[a-z0-9=_/\.-\]*;" $i mldir
-   set mldir [string trimright $mldir "\;@"]
-   if { "$mldir" == "." } {
+   set multi_dir_x [remote_exec host "$compiler" 

[PATCH libffi 4/4] Correct indentation throughout `libffi-init'

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
---
 testsuite/lib/libffi.exp |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

libffi-init-whitespace.diff
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -303,7 +303,7 @@ proc libffi-init { args } {
}
set compiler "${gccdir}/xgcc"
}
-verbose "gccdir $gccdir"
+   verbose "gccdir $gccdir"
 
set shlib_ext [get_shlib_extension]
set libgcc_s_x [remote_exec host "$compiler" \
@@ -315,8 +315,8 @@ proc libffi-init { args } {
}
verbose "libgcc_dir $libgcc_dir"
 
-set ld_library_path "."
-append ld_library_path ":${gccdir}"
+   set ld_library_path "."
+   append ld_library_path ":${gccdir}"
 
set multi_dir_x [remote_exec host "$compiler" "-print-multi-directory"]
set multi_lib_x [remote_exec host "$compiler" "-print-multi-lib"]


[PATCH libffi 2/4] Use a documented way to pass $compiler_vendor to DejaGNU

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Use Autoconf substitution in the template used for extra DejaGNU site 
configuration, which is a documented supported way to pass information 
from the `configure' script, rather than resorting to a hack with 
extracting an undocumented internal setting from `config.log' to pass 
the compiler vendor to DejaGNU.  No functional change (and no risk of 
breakage with some Autoconf version anymore).

Use AM_SUBST_NOTMAKE with the new substitution so as not to place it in 
Makefile.in files, where it is not needed, and set the Autmoake version 
requirement accordingly.
---
Hi,

 I chose to use AM_SUBST_NOTMAKE so as not to clutter Makefile.in files 
with the new variable as Automake does that by default.  That however 
requires the use of Automake 1.11 or newer.  By the look of our sources 
that shouldn't be an issue as far as I can tell, but the macro invocation 
can be dropped along with the requirement if it would.

  Maciej
---
 Makefile.am  |3 ++-
 configure.ac |2 ++
 testsuite/lib/libffi.exp |4 
 testsuite/local.exp.in   |1 +
 4 files changed, 5 insertions(+), 5 deletions(-)

libffi-compiler-vendor.diff
Index: libffi/Makefile.am
===
--- libffi.orig/Makefile.am
+++ libffi/Makefile.am
@@ -1,6 +1,7 @@
 ## Process this with automake to create Makefile.in
 
-AUTOMAKE_OPTIONS = foreign subdir-objects
+# Automake 1.11 needed for AM_SUBST_NOTMAKE.
+AUTOMAKE_OPTIONS = 1.11 foreign subdir-objects
 
 ACLOCAL_AMFLAGS = -I m4
 
Index: libffi/configure.ac
===
--- libffi.orig/configure.ac
+++ libffi/configure.ac
@@ -45,6 +45,8 @@ AC_CONFIG_MACRO_DIR([m4])
 AC_CHECK_SIZEOF([size_t])
 
 AX_COMPILER_VENDOR
+AC_SUBST([compiler_vendor], [$ax_cv_c_compiler_vendor])
+AM_SUBST_NOTMAKE([compiler_vendor])
 AX_CC_MAXOPT
 # The AX_CFLAGS_WARN_ALL macro doesn't currently work for sunpro
 # compiler.
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -286,10 +286,6 @@ proc libffi-init { args } {
 
 verbose "libffi $blddirffi"
 
-# Which compiler are we building with?
-set tmp [grep "$blddirffi/config.log" "^ax_cv_c_compiler_vendor.*$"]
-regexp -- {^[^=]*=(.*)$} $tmp nil compiler_vendor
-
 if { [string match $compiler_vendor "gnu"] } {
 set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
 if {$gccdir != ""} {
Index: libffi/testsuite/local.exp.in
===
--- libffi.orig/testsuite/local.exp.in
+++ libffi/testsuite/local.exp.in
@@ -1,2 +1,3 @@
 set CC_FOR_TARGET "@CC@"
 set CXX_FOR_TARGET "@CXX@"
+set compiler_vendor "@compiler_vendor@"


[PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Use an Autoconf template rather an inline piece of scriptery to set 
DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX 
respectively, making it easier to maintain and making it take advantage 
of Automake's dependency and rule generation.  Relocate the generated 
`local.exp' file to within testsuite/ so as to make its regeneration 
rule to actually work, i.e. (in testsuite/Makefile.in):

EXTRA_DEJAGNU_SITE_CONFIG = local.exp
site.exp: Makefile $(EXTRA_DEJAGNU_SITE_CONFIG)
[...]
local.exp: $(top_builddir)/config.status $(srcdir)/local.exp.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@

It wouldn't work if the regeneration rule was placed in the top-level 
Makefile.in, which is what Automake would faithfully do if `local.exp' 
stayed in the top level directory.
---
Hi,

 I think having individual AC_CONFIG_FILES macro invocations for each 
output file or group of files would make this change (and code itself) 
more readable, however it hasn't been done before and I decided not to 
change the style on this occasion.  It may make sense as a follow-up 
clean-up.

  Maciej
---
 Makefile.am|3 ---
 configure.ac   |7 +--
 testsuite/Makefile.am  |2 +-
 testsuite/local.exp.in |2 ++
 4 files changed, 4 insertions(+), 10 deletions(-)

libffi-test-cc-for-target-template.diff
Index: libffi/Makefile.am
===
--- libffi.orig/Makefile.am
+++ libffi/Makefile.am
@@ -23,9 +23,6 @@ EXTRA_DIST = LICENSE ChangeLog.old
\
libtool-ldflags libtool-version configure.host README.md\
libffi.map.in LICENSE-BUILDTOOLS msvc_build make_sunver.pl  
 
-# local.exp is generated by configure
-DISTCLEANFILES = local.exp
-
 # Subdir rules rely on $(FLAGS_TO_PASS)
 FLAGS_TO_PASS = $(AM_MAKEFLAGS)
 
Index: libffi/configure.ac
===
--- libffi.orig/configure.ac
+++ libffi/configure.ac
@@ -56,11 +56,6 @@ if test "x$GCC" = "xyes"; then
   CFLAGS="$CFLAGS -fexceptions"
 fi
 
-cat > local.exp <

[PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite

2020-04-03 Thread Maciej W. Rozycki via Gcc-patches
Hi,

 In the course of a discussion at one of the GCC mailing lists here: 
 I have 
realised that some parts related to libffi testing have not been merged to 
GCC, and they are needed to choose the right compiler in a cross-compiler 
build environment where the build root option has been used.

 Additionally the right target run-time loader's library path has to be 
set via the LD_LIBRARY_PATH environment variable for running the test 
suite in a cross-compilation environment where the location of the host 
libraries is obviously irrelevant.

 We are keen to keep the GCC's copy of libffi as close as possible to the 
upstream version however while usable the current solution has some issues 
which we would rather avoid.  I have therefore decided to address some of 
them with the intent to have the result backported to GCC.  As it stands 
I'm told the current version of libffi cannot be fully merged to GCC, as 
there have been an ABI change that will require technical evaluation.  So 
the intent has been to backport the changes proposed here individually.

 See the individual change descriptions and any further discussion 
included for full details of each patch proposed.

 These changes have been regression-tested with the `x86_64-linux-gnu' 
native configuration, and also the `x86_64-linux-gnu' host and the 
`riscv64-linux-gnu' target using RISC-V QEMU in the Linux user emulation 
mode as the target board.  In the latter case I actually dropped libffi 
into GCC as a replacement of the version included there, with a minor 
update like below (+script regeneration) to add multilib support.

 Any questions, comments, or concerns?  Otherwise, please apply.

  Maciej

Index: gcc/libffi/Makefile.am
===
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -2,7 +2,7 @@
 
 AUTOMAKE_OPTIONS = foreign subdir-objects
 
-ACLOCAL_AMFLAGS = -I m4
+ACLOCAL_AMFLAGS = -I m4 -I ../config
 
 SUBDIRS = include testsuite man
 if BUILD_DOCS
@@ -158,3 +158,12 @@ AM_CCASFLAGS = $(AM_CPPFLAGS)
if [ -d $(top_srcdir)/.git ] ; then (cd $(top_srcdir); git log 
--no-decorate) ; else echo 'See git log for history.' ; fi > 
$(distdir)/ChangeLog
s=`awk '/was released on/{ print NR; exit}' $(top_srcdir)/README.md`; 
tail -n +$$(($$s-1)) $(top_srcdir)/README.md > $(distdir)/README.md
 
+# Multilib support.  Automake should provide these on its own.
+all-recursive: all-multi
+install-recursive: install-multi
+mostlyclean-recursive: mostlyclean-multi
+clean-recursive: clean-multi
+distclean-recursive: distclean-multi
+maintainer-clean-recursive: maintainer-clean-multi
+
+include $(top_srcdir)/../multilib.am
Index: gcc/libffi/configure.ac
===
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -5,6 +5,8 @@ AC_PREREQ(2.68)
 AC_INIT([libffi], [3.3], [http://github.com/libffi/libffi/issues])
 AC_CONFIG_HEADERS([fficonfig.h])
 
+AM_ENABLE_MULTILIB(, ..)
+
 AC_CANONICAL_SYSTEM
 target_alias=${target_alias-$host_alias}
 


[PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
Hi!

On the following testcase, in gdb ptype S::m1 prints long as return
type, but all the other methods show void instead.
PR53756 added code to add_type_attribute if the return type is
auto/decltype(auto), but we actually should look through references,
pointers and qualifiers.
Haven't included there DW_TAG_atomic_type, because I think at least ATM
one can't use that in C++.  Not sure about DW_TAG_array_type or what else
could be deduced.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-04-04  Domani Hannes  
Jakub Jelinek  

PR debug/94459
* dwarf2out.c (gen_subprogram_die): Look through references, pointers
and qualifiers when checking if in-class DIE had an 'auto' or
'decltype(auto)' return type to emit type again on definition.

* g++.dg/debug/pr94459.C: New test.

--- gcc/dwarf2out.c.jj  2020-04-03 10:04:44.704972108 +0200
+++ gcc/dwarf2out.c 2020-04-03 17:52:48.909483818 +0200
@@ -22905,11 +22905,19 @@ gen_subprogram_die (tree decl, dw_die_re
  != (unsigned) s.column))
add_AT_unsigned (subr_die, DW_AT_decl_column, s.column);
 
- /* If the prototype had an 'auto' or 'decltype(auto)' return type,
+ /* If the prototype had a cv 'auto' or 'decltype(auto)' return type,
 emit the real type on the definition die.  */
  if (is_cxx () && debug_info_level > DINFO_LEVEL_TERSE)
{
  dw_die_ref die = get_AT_ref (old_die, DW_AT_type);
+ while (die
+&& (die->die_tag == DW_TAG_reference_type
+|| die->die_tag == DW_TAG_rvalue_reference_type
+|| die->die_tag == DW_TAG_pointer_type
+|| die->die_tag == DW_TAG_const_type
+|| die->die_tag == DW_TAG_volatile_type
+|| die->die_tag == DW_TAG_restrict_type))
+   die = get_AT_ref (die, DW_AT_type);
  if (die == auto_die || die == decltype_auto_die)
add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
TYPE_UNQUALIFIED, false, context_die);
--- gcc/testsuite/g++.dg/debug/pr94459.C.jj 2020-04-03 18:06:28.234725520 
+0200
+++ gcc/testsuite/g++.dg/debug/pr94459.C2020-04-03 18:05:59.287104932 
+0200
@@ -0,0 +1,49 @@
+// PR debug/94459
+// { dg-do compile { target c++11 } }
+// { dg-options "-g -dA" }
+
+template 
+struct S
+{
+  T v;
+  S () : v (0) {}
+  auto m1 () { return v; }
+  auto  () { return v; }
+  auto & () { return (T&&)v; }
+  const auto m4 () { return v; }
+  const auto  () { return v; }
+  const auto & () { return (T&&)v; }
+  volatile auto m7 () { return v; }
+  volatile auto  () { return v; }
+  volatile auto & () { return (T&&)v; }
+  volatile const auto m10 () { return v; }
+  volatile const auto  () { return v; }
+  volatile const auto & () { return (T&&)v; }
+  const volatile auto m13 () { return v; }
+  const volatile auto  () { return v; }
+  const volatile auto & () { return (T&&)v; }
+#ifndef __STRICT_ANSI__
+  __restrict const volatile auto & () { return (T&&)v; }
+  const __restrict auto  () { return v; }
+#endif
+};
+
+S s, u, v;
+
+long
+foo ()
+{
+  return s.m1 () + s.m2 () + s.m3 () + s.m4 () + s.m5 ()
++ s.m6 () + s.m7 () + s.m8 () + s.m9 () + s.m10 ()
++ s.m11 () + s.m12 () + s.m13 () + s.m14 () + s.m15 ()
+#ifndef __STRICT_ANSI__
++ u.m16 () + v.m17 ()
+#endif
++ 0;
+}
+
+int
+main ()
+{
+  return foo ();
+}

Jakub



Re: [PATCH] cselib: Don't consider SP_DERIVED_VALUE_P values as useless [PR94468]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
On Fri, Apr 03, 2020 at 07:42:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Or, to avoid the repetitive code, should I introduce
> static bool
> cselib_useless_value_p (cselib_val *v)
> {
>   return (v->locs == 0
> && !PRESERVED_VALUE_P (v->val_rtx)
> && !SP_DERIVED_VALUE_P (v->val_rtx)));
> }
> predicate and use it in those 6 spots?

Here is the patch variant with the above helper.
Also bootstrapped/regtested on x86_64-linux and i686-linux.

2020-04-04  Jakub Jelinek  

PR rtl-optimization/94468
* cselib.c (references_value_p): Formatting fix.
(cselib_useless_value_p): New function.
(discard_useless_locs, discard_useless_values,
cselib_invalidate_regno_val, cselib_invalidate_mem,
cselib_record_set): Use it instead of
v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx).

* g++.dg/opt/pr94468.C: New test.

--- gcc/cselib.c.jj 2020-04-02 14:28:02.620577679 +0200
+++ gcc/cselib.c2020-04-03 17:08:54.295282018 +0200
@@ -629,8 +629,8 @@ references_value_p (const_rtx x, int onl
   int i, j;
 
   if (GET_CODE (x) == VALUE
-  && (! only_useless ||
- (CSELIB_VAL_PTR (x)->locs == 0 && !PRESERVED_VALUE_P (x
+  && (! only_useless
+ || (CSELIB_VAL_PTR (x)->locs == 0 && !PRESERVED_VALUE_P (x
 return 1;
 
   for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
@@ -646,6 +646,16 @@ references_value_p (const_rtx x, int onl
   return 0;
 }
 
+/* Return true if V is a useless VALUE and can be discarded as such.  */
+
+static bool
+cselib_useless_value_p (cselib_val *v)
+{
+  return (v->locs == 0
+ && !PRESERVED_VALUE_P (v->val_rtx)
+ && !SP_DERIVED_VALUE_P (v->val_rtx));
+}
+
 /* For all locations found in X, delete locations that reference useless
values (i.e. values without any location).  Called through
htab_traverse.  */
@@ -666,7 +676,7 @@ discard_useless_locs (cselib_val **x, vo
p = &(*p)->next;
 }
 
-  if (had_locs && v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (had_locs && cselib_useless_value_p (v))
 {
   if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_debug_values++;
@@ -684,7 +694,7 @@ discard_useless_values (cselib_val **x,
 {
   cselib_val *v = *x;
 
-  if (v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (v->locs == 0 && cselib_useless_value_p (v))
 {
   if (cselib_discard_hook)
cselib_discard_hook (v);
@@ -2370,7 +2380,7 @@ cselib_invalidate_regno_val (unsigned in
}
 }
 
-  if (had_locs && v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (had_locs && cselib_useless_value_p (v))
 {
   if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_debug_values++;
@@ -2515,7 +2525,7 @@ cselib_invalidate_mem (rtx mem_rtx)
  unchain_one_elt_loc_list (p);
}
 
-  if (had_locs && v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (had_locs && cselib_useless_value_p (v))
{
  if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_debug_values++;
@@ -2593,14 +2603,14 @@ cselib_record_set (rtx dest, cselib_val
  REG_VALUES (dreg)->elt = src_elt;
}
 
-  if (src_elt->locs == 0 && !PRESERVED_VALUE_P (src_elt->val_rtx))
+  if (cselib_useless_value_p (src_elt))
n_useless_values--;
   new_elt_loc_list (src_elt, dest);
 }
   else if (MEM_P (dest) && dest_addr_elt != 0
   && cselib_record_memory)
 {
-  if (src_elt->locs == 0 && !PRESERVED_VALUE_P (src_elt->val_rtx))
+  if (cselib_useless_value_p (src_elt))
n_useless_values--;
   add_mem_for_addr (dest_addr_elt, src_elt, dest);
 }
--- gcc/testsuite/g++.dg/opt/pr94468.C.jj   2020-04-03 17:16:38.804457422 
+0200
+++ gcc/testsuite/g++.dg/opt/pr94468.C  2020-04-03 17:16:18.450756522 +0200
@@ -0,0 +1,57 @@
+// PR rtl-optimization/94468
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2" }
+// { dg-additional-options "-fPIC" { target fpic } }
+
+bool a();
+enum b {};
+class c;
+template  struct d;
+template  struct d {
+  typedef e i;
+};
+struct j { j(void(int, j *, c *, void **, bool *)) {} };
+template  struct m : public j {
+  l ab;
+  static void ac(int, j *, c *, void **, bool *);
+  m(l f) : j(ac), ab(f) {}
+};
+b ad;
+struct c {
+  template 
+  void ae(typename d::i *p, n af, typename d::i *ag, o ah) {
+ai(p, , ag, , new m(ah), ad, ::i::aj);
+  }
+  void ai(c *, void *, c *, void *, j *, b, int *);
+};
+struct r : public c { static int aj; void t(); };
+struct al : public c {
+  static int aj;
+  void am();
+  void ao();
+  void ap();
+};
+struct aq { aq(const int &, const int & = int()); };
+struct ar : public c { ~ar(); };
+struct as : public ar {
+  as();
+  void at();
+  void au();
+  void av();
+};
+struct u : public c { void ax(); };
+struct ay { int az(); };
+struct ba : public c { static int aj; void bb(); };
+struct bc : public al { bc() { if (a()) am(); } };
+as::as() {
+ 

[PATCH] i386: Simplify {,v}ph{add,sub{,s}{w,d} insn patterns [PR94460]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
Hi!

As mentioned in the previous PR94460 patch, the RTL patterns look too
large/complicated, we can simplify them by just performing two 2 arg
permutations to move the arguments into the right spots and then just
doing the plus/minus (or signed saturation version thereof).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1?

2020-04-04  Jakub Jelinek  

PR target/94460
* config/i386/sse.md (avx2_phwv16hi3,
ssse3_phwv8hi3, ssse3_phwv4hi3,
avx2_phdv8si3, ssse3_phdv4si3,
ssse3_phdv2si3): Simplify RTL patterns.

--- gcc/config/i386/sse.md.jj   2020-04-03 10:21:51.110564277 +0200
+++ gcc/config/i386/sse.md  2020-04-03 11:55:04.455963720 +0200
@@ -16038,73 +16038,23 @@ (define_code_iterator ssse3_plusminus [p
 
 (define_insn "avx2_phwv16hi3"
   [(set (match_operand:V16HI 0 "register_operand" "=x")
-   (vec_concat:V16HI
- (vec_concat:V8HI
-   (vec_concat:V4HI
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI
-   (match_operand:V16HI 1 "register_operand" "x")
-   (parallel [(const_int 0)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 1)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 2)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 3)]
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 4)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 5)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 6)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 7)])
-   (vec_concat:V4HI
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI
-   (match_operand:V16HI 2 "nonimmediate_operand" "xm")
-   (parallel [(const_int 0)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 1)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 2)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 3)]
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 4)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 5)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 6)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 7)]))
- (vec_concat:V8HI
-   (vec_concat:V4HI
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 8)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 9)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 10)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 11)]
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 12)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 13)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 1) (parallel [(const_int 14)]))
- (vec_select:HI (match_dup 1) (parallel [(const_int 15)])
-   (vec_concat:V4HI
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 8)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 9)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 10)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 11)]
- (vec_concat:V2HI
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 12)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 13)])))
-   (ssse3_plusminus:HI
- (vec_select:HI (match_dup 2) (parallel [(const_int 14)]))
- (vec_select:HI (match_dup 2) (parallel [(const_int 
15)]]
+   (ssse3_plusminus:V16HI
+ (vec_select:V16HI
+   (vec_concat:V32HI
+ (match_operand:V16HI 1 "register_operand" "x")
+ (match_operand:V16HI 2 "nonimmediate_operand" "xm"))
+   (parallel
+ [(const_int 0) (const_int 2) (const_int 4) (const_int 6)
+  (const_int 16) (const_int 18) (const_int 20) (const_int 22)
+  (const_int 8) (const_int 10) (const_int 12) (const_int 14)
+  (const_int 24) (const_int 26) (const_int 

[committed] openmp: Fix ICE on #pragma omp parallel master in template [PR94477]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase ICEs, because for parallel combined with some
other construct we initialize the omp_parallel_combined_clauses pointer
and expect the construct combined with it to clear it after it no longer
needs it, but OMP_MASTER didn't do that.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for backporting.

2020-04-04  Jakub Jelinek  

PR c++/94477
* pt.c (tsubst_expr) : Clear
omp_parallel_combined_clauses.

* g++.dg/gomp/pr94477.C: New test.

--- gcc/cp/pt.c.jj  2020-04-03 20:28:50.989754551 +0200
+++ gcc/cp/pt.c 2020-04-03 21:54:29.754337004 +0200
@@ -18467,8 +18467,10 @@ tsubst_expr (tree t, tree args, tsubst_f
   add_stmt (t);
   break;
 
-case OMP_SECTION:
 case OMP_MASTER:
+  omp_parallel_combined_clauses = NULL;
+  /* FALLTHRU */
+case OMP_SECTION:
   stmt = push_stmt_list ();
   RECUR (OMP_BODY (t));
   stmt = pop_stmt_list (stmt);
--- gcc/testsuite/g++.dg/gomp/pr94477.C.jj  2020-04-03 21:55:10.575740787 
+0200
+++ gcc/testsuite/g++.dg/gomp/pr94477.C 2020-04-03 21:54:52.388006422 +0200
@@ -0,0 +1,18 @@
+// PR c++/94477
+// { dg-do compile }
+
+void foo ();
+
+template 
+void
+bar ()
+{
+  #pragma omp parallel master
+  foo ();
+}
+
+void
+baz ()
+{
+  bar<0> ();
+}

Jakub



Re: [PATCH] Fix some incorrect Changelog dates

2020-04-03 Thread Jakub Jelinek via Gcc-patches
On Fri, Apr 03, 2020 at 03:53:47PM -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
> 
> It seems that some dates in gcc/ChangeLog-2019 and
> gcc/testsuite/ChangeLog-2019 are incorrect.

If we want to fix these, there are many more suspect cases.
I guess we'd need to look at each of those, some might be acceptable,
while generally people should use the current date in the ChangeLog entry,
sometimes people just put the date when they wrote a patch.

Dates in the future are clearly wrong, like the ones you've spotted, that
is:
gcc/ChangeLog-2011:2012-12-15  Richard Guenther  
gcc/ChangeLog-2015:2017-06-17  Andrew MacLeod  
gcc/ChangeLog-2017:2018-07-19  Segher Boessenkool  
gcc/ChangeLog-2019:2020-12-31  Richard Sandiford  
gcc/ChangeLog-2019:2020-12-31  Richard Sandiford  
gcc/testsuite/ChangeLog-2011:2012-12-29  Kai Tietz  
gcc/testsuite/ChangeLog-2011:2012-12-15  Richard Guenther  
gcc/testsuite/ChangeLog-2019:2020-12-31  Richard Sandiford  

gcc/testsuite/ChangeLog-2019:2020-12-31  Richard Sandiford  

gcc/d/ChangeLog-2012:2013-02-15  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-14  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-13  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-07  Johannes Pfau  
gcc/d/ChangeLog-2012:2013-02-05  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-01  Johannes Pfau  
libstdc++-v3/ChangeLog-2012:2013-03-21  Andreas Tobler  

Another thing is that sometimes, especially in January, one uses past year
but correct date based on the surrounding dates, that is something that
could be fixed too.

Here is the full list of suspect years:

for i in `seq 2000 2019`; do find * -name ChangeLog-$i | xargs grep ^2 | grep 
-v $i:$i; done
gcc/ChangeLog-2001:2000-12-27  Phil Edwards  
gcc/cp/ChangeLog-2001:2000-12-22  Mike Stump  
gcc/ada/ChangeLog-2002:2001-05-02  John David Anglin  
gcc/ada/ChangeLog-2002:2001-03-28  Robert Dewar  
gcc/ada/ChangeLog-2002:2001-03-28  Ed Schonberg  
libstdc++-v3/ChangeLog-2002:2001-02-14  Joel Sherrill  
gcc/ChangeLog-2003:2002-12-31  Larin Hennessy  
libstdc++-v3/ChangeLog-2003:2002-02-11  DJ Delorie  
libstdc++-v3/ChangeLog-2003:2002-02-04  Jonathan Wakely  
libstdc++-v3/ChangeLog-2003:2002-02-04  Jonathan Wakely  
libstdc++-v3/ChangeLog-2004:2003-01-27  Jerry Quinn  
gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog-2005:2003-06-04  J"orn Rennecke 

gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog-2005:2002-07-06  Alexandre Oliva 
 
gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog-2005:2001-02-15  Alexandre Oliva 
 
gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog-2005:2000-05-28  Alexandre Oliva 
 
gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog-2005:2000-04-19  Alexandre Oliva 
 
libgfortran/ChangeLog-2006:2005-02-06  Thomas Koenig  
gcc/fortran/ChangeLog-2009:2008-12-08  Daniel Kraft  
gcc/fortran/ChangeLog-2009:2008-08-17  Paul Thomas  
gcc/fortran/ChangeLog-2009:2008-07-09  Paul Thomas  
gcc/fortran/ChangeLog-2009:2008-07-08  Paul Thomas  
gcc/cp/ChangeLog-2009:2008-07-09  Simon Martin  
gcc/testsuite/ChangeLog-2009:2008-12-08  Daniel Kraft  
gcc/testsuite/ChangeLog-2009:2008-08-17  Paul Thomas  
gcc/testsuite/ChangeLog-2009:2007-07-26  Simon Martin  

gcc/testsuite/ChangeLog-2009:2008-07-09  Paul Thomas  
gcc/testsuite/ChangeLog-2009:2008-04-24  Doug Kwan  
gcc/fortran/ChangeLog-2010:2009-07-23  Paul Thomas  
gcc/ChangeLog-2010:2009-09-14  Vladimir Makarov  
gcc/ChangeLog-2010:2009-01-07  Steven Bosscher  
gcc/ChangeLog-2010:2009-01-03  Steven Bosscher  
gcc/testsuite/ChangeLog-2010:2009-04-30  Steven Bosscher  
gcc/testsuite/ChangeLog-2010:2009-04-29  Paul Thomas  
gcc/testsuite/ChangeLog-2010:2009-01-04  Tobias Burnus  
gcc/ChangeLog-2011:2012-12-15  Richard Guenther  
gcc/ChangeLog-2011:2010-11-02  Richard Guenther  
gcc/ChangeLog-2011:2010-10-28  Richard Guenther  
gcc/ChangeLog-2011:2010-10-27  Richard Guenther  
gcc/ChangeLog-2011:2001-10-06  Richard Henderson  
gcc/ChangeLog-2011:2001-10-06  Richard Henderson  
gcc/cp/ChangeLog-2011:2010-05-31  Fabien Chêne  
gcc/testsuite/ChangeLog-2011:2012-12-29  Kai Tietz  
gcc/testsuite/ChangeLog-2011:2012-12-15  Richard Guenther  
gcc/testsuite/ChangeLog-2011:2010-11-02  Richard Guenther  
gcc/testsuite/ChangeLog-2011:2010-11-15  Fabien Chêne  
gcc/testsuite/ChangeLog-2011:2010-04-04  Thomas Koenig  
gcc/testsuite/ChangeLog-2011:2010-04-04  Thomas Koenig  
gcc/testsuite/ChangeLog-2011:2010-03-21  Thomas Koenig  
gcc/testsuite/ChangeLog-2011:2001-02-05  Thomas Koenig  
gcc/fortran/ChangeLog-2012:2011-01-14  Tobias Burnus  
gcc/ChangeLog-2012:2010-12-01  Xinliang David Li  
gcc/ChangeLog-2012:2010-11-27  Dehao Chen  
gcc/d/ChangeLog-2012:2013-02-15  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-14  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-13  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-07  Johannes Pfau  
gcc/d/ChangeLog-2012:2013-02-05  Iain Buclaw  
gcc/d/ChangeLog-2012:2013-02-01  Johannes Pfau  
gcc/cp/ChangeLog-2012:2011-12-15  Dodji Seketeli  
gcc/testsuite/ChangeLog-2012:2010-04-10  Michael Matz  

libgcc patch committed: Avoid hooks in split-stack code

2020-04-03 Thread Ian Lance Taylor via Gcc-patches
The split-stack code invokes mmap and munmap with a limited amount of
stack space.  That is fine when the functions just make a system call,
but it's not fine when programs use LD_PRELOAD or linker tricks to add
hooks to mmap/munmap.  Those hooks may use too much stack space,
leading to an obscure program crash.

Avoid that at least on GNU/Linux by calling __mmap/__munmap instead.

Bootstrapped and ran Go and split-stack tests on x86_64-pc-linux-gnu.
Committed to mainline.

Ian

2020-04-03  Ian Lance Taylor  

* generic-morestack.c: On GNU/Linux use __mmap/__munmap rather
than mmap/munmap, to avoid hooks.
diff --git a/libgcc/generic-morestack.c b/libgcc/generic-morestack.c
index c26dba1ae4a..bb9f67a7366 100644
--- a/libgcc/generic-morestack.c
+++ b/libgcc/generic-morestack.c
@@ -53,6 +53,23 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 
 #include "generic-morestack.h"
 
+/* Some systems use LD_PRELOAD or similar tricks to add hooks to
+   mmap/munmap.  That breaks this code, because when we call mmap
+   there is enough stack space for the system call but there is not,
+   in general, enough stack space to run a hook.  At least when using
+   glibc on GNU/Linux we can avoid the problem by calling __mmap and
+   __munmap.  */
+
+#ifdef __gnu_linux__
+
+extern void *__mmap (void *, size_t, int, int, int, off_t);
+extern int __munmap (void *, size_t);
+
+#define mmap __mmap
+#define munmap __munmap
+
+#endif /* defined(__gnu_linux__) */
+
 typedef unsigned uintptr_type __attribute__ ((mode (pointer)));
 
 /* This file contains subroutines that are used by code compiled with


[PATCH] Fix some incorrect Changelog dates

2020-04-03 Thread Zackery Spytz via Gcc-patches
Hello,

It seems that some dates in gcc/ChangeLog-2019 and
gcc/testsuite/ChangeLog-2019 are incorrect.

diff --git a/gcc/ChangeLog-2019 b/gcc/ChangeLog-2019
index 9f5782fd458..1acf57d49b9 100644
--- a/gcc/ChangeLog-2019
+++ b/gcc/ChangeLog-2019
@@ -1,10 +1,10 @@
-2020-12-31  Richard Sandiford  
+2019-12-31  Richard Sandiford  

* tree-vect-stmts.c (vectorizable_condition): Only nullify cond_expr
if we've created a new condition.  Don't nullify it if we've decided
to keep it and then invert the result.

-2020-12-31  Richard Sandiford  
+2019-12-31  Richard Sandiford  

* tree-vect-loop-manip.c (create_lcssa_for_virtual_phi): Return
the incoming virtual operand definition.
diff --git a/gcc/testsuite/ChangeLog-2019 b/gcc/testsuite/ChangeLog-2019
index b3211aafefc..d94ed548696 100644
--- a/gcc/testsuite/ChangeLog-2019
+++ b/gcc/testsuite/ChangeLog-2019
@@ -1,8 +1,8 @@
-2020-12-31  Richard Sandiford  
+2019-12-31  Richard Sandiford  

* gcc.dg/vect/vect-cond-reduc-6.c: New test.

-2020-12-31  Richard Sandiford  
+2019-12-31  Richard Sandiford  

* gcc.dg/vect/vect-epilogues-2.c: New test.



Zackery


Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread Segher Boessenkool
On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote:
> On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu via Gcc-patches wrote:
> > Seems PR94393?  Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const 
> > for DImode.
> > I tried unsigned long like 0xabcd87654321, 0xabcd87654321 and 
> > 0xc000ULL, 
> > All of them are outside of loop even without my patch.  No difference with 
> > or without
> > Alan's patch.
> 
> Segher probably meant the part I'm working on and haven't posted yet,
> fixing lots of problems with rs6000_rtx_costs.

I meant PR94393 in fact, but yeah, this is connected *everywhere* :-)

> One of the improvements
> I'm aiming for is that we should be able to emit code that loads
> constants from memory without following optimisation passes converting
> the loads from memory to those long sequences of dependent instructions.

Yeah.  Looking forward to it :-)


Segher


Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread Segher Boessenkool
Hi!

On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu wrote:
> Currently 286r.split2 will split "12:%9:DI=0x87654321" to lis+ori by
> rs6000_emit_set_const of define_split, do you mean add new 
> define_insn_and_split
> to do the split?  Another patch to do this after this one goes upstream in 
> stage 1?

I mean a splitter that recognises
  reg := reg + imm
for a big immediate, and then does addis+addi again if that is the best
way to do it.

We expand as a load of the 32-bit constant, which means it can be hoisted
just fine, and when we can use paddi we can; but when we cannot, we can
still split it again.

> > This also links in with Alan's work on big immediates, and with paddi
> > insns, etc.
> 
> Seems PR94393?

Yes, PR94393.  And everything else that will show up if we start pulling
at that string (which we should now, btw, for paddi).


Segher


Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

2020-04-03 Thread Patrick Palka via Gcc-patches
On Fri, 3 Apr 2020, Patrick Palka wrote:

> On Fri, 3 Apr 2020, Jason Merrill wrote:
> 
> > On 4/2/20 2:19 PM, Patrick Palka wrote:
> > > On Thu, 2 Apr 2020, Patrick Palka wrote:
> > > 
> > > > This PR reveals that cxx_eval_bare_aggregate and 
> > > > cxx_eval_store_expression
> > > > do
> > > > not anticipate that a constructor element's initializer could mutate the
> > > > underlying CONSTRUCTOR.  Evaluation of the initializer could add new
> > > > elements to
> > > > the underlying CONSTRUCTOR, thereby potentially invalidating any 
> > > > pointers
> > > > to
> > > > or assumptions about the CONSTRUCTOR's elements, and so these routines
> > > > should be
> > > > prepared for that.
> > > > 
> > > > To fix this problem, this patch makes cxx_eval_bare_aggregate and
> > > > cxx_eval_store_expression recompute the pointer to the constructor_elt's
> > > > through
> > > > which we're assigning, after it evaluates the initializer.  Care is 
> > > > taken
> > > > to
> > > > to make the common case where the initializer does not modify the
> > > > underlying
> > > > CONSTRUCTOR as fast as before.
> > > 
> > > Also, with this patch, I'm not totally sure but I think we might not
> > > need the special preeval handling in cxx_eval_store_expression anymore.
> > > I could try to remove it in a subsequent patch.
> > 
> > I think for C++17 order of evaluation it's better to keep preevaluating when
> > we can.
> 
> Sounds good.
> 
> > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > PR c++/94205
> > > > PR c++/94219
> > > > * constexpr.c (get_or_insert_ctor_field): Split out (while 
> > > > adding
> > > > support for VECTOR_TYPEs, and optimizations for the common case)
> > > > from ...
> > > > (cxx_eval_store_expression): ... here.  Rename local variable
> > > > 'changed_active_union_member_p' to 'activated_union_member_p'.  
> > > > Record
> > > > the sequence of indexes into 'indexes' that yields the 
> > > > subobject we're
> > > > assigning to.  Record the integer offsets of the constructor 
> > > > indexes
> > > > we're assigning through into 'index_pos_hints'.  After 
> > > > evaluating the
> > > > initializer of the store expression, recompute 'valp' using 
> > > > 'indexes'
> > > > and 'index_pos_hints' as hints.
> > > > (cxx_eval_bare_aggregate): Tweak comments.  Use
> > > > get_or_insert_ctor_field
> > > > to recompute the pointer to the constructor_elt we're assigning
> > > > through
> > > > after evaluating each initializer.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > PR c++/94205
> > > > PR c++/94219
> > > > * g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
> > > > * g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
> > > > * g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
> > > > * g++.dg/cpp1z/lambda-this5.C: New test.
> > > > ---
> > > >   gcc/cp/constexpr.c| 252 +++---
> > > >   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C |  19 ++
> > > >   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C |  21 ++
> > > >   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C |  22 ++
> > > >   gcc/testsuite/g++.dg/cpp1z/lambda-this5.C |  11 +
> > > >   5 files changed, 228 insertions(+), 97 deletions(-)
> > > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C
> > > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C
> > > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C
> > > >   create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this5.C
> > > > 
> > > > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > > > index 91f0c3ba269..b4173c595f0 100644
> > > > --- a/gcc/cp/constexpr.c
> > > > +++ b/gcc/cp/constexpr.c
> > > > @@ -3151,6 +3151,97 @@ find_array_ctor_elt (tree ary, tree dindex, bool
> > > > insert)
> > > > return -1;
> > > >   }
> > > >   +/* Return a pointer to the constructor_elt of CTOR which matches 
> > > > INDEX.
> > > > If no
> > > > +   matching constructor_elt exists, then add one to CTOR.
> > > > +
> > > > +   As an optimization, if POS_HINT is non-negative then it is used as a
> > > > guess
> > > > +   for the (integer) index of the matching constructor_elt within CTOR.
> > > > */
> > > > +
> > > > +static constructor_elt *
> > > > +get_or_insert_ctor_field (tree ctor, tree index, int pos_hint)
> > > > +{
> > > > +  tree type = TREE_TYPE (ctor);
> > > > +  if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
> > > > +{
> > > > +  CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, 
> > > > NULL_TREE);
> > > > +  return _ELTS (ctor)->last();
> > > > +}
> > > > +  else if (TREE_CODE (type) == ARRAY_TYPE || TREE_CODE (type) ==
> > > > VECTOR_TYPE)
> > > > +{
> > > > +  HOST_WIDE_INT i = find_array_ctor_elt (ctor, index,
> > > > /*insert*/true);
> > > > +  gcc_assert (i >= 0);
> > > > +  constructor_elt 

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

2020-04-03 Thread Patrick Palka via Gcc-patches
On Fri, 3 Apr 2020, Jason Merrill wrote:

> On 4/2/20 2:19 PM, Patrick Palka wrote:
> > On Thu, 2 Apr 2020, Patrick Palka wrote:
> > 
> > > This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression
> > > do
> > > not anticipate that a constructor element's initializer could mutate the
> > > underlying CONSTRUCTOR.  Evaluation of the initializer could add new
> > > elements to
> > > the underlying CONSTRUCTOR, thereby potentially invalidating any pointers
> > > to
> > > or assumptions about the CONSTRUCTOR's elements, and so these routines
> > > should be
> > > prepared for that.
> > > 
> > > To fix this problem, this patch makes cxx_eval_bare_aggregate and
> > > cxx_eval_store_expression recompute the pointer to the constructor_elt's
> > > through
> > > which we're assigning, after it evaluates the initializer.  Care is taken
> > > to
> > > to make the common case where the initializer does not modify the
> > > underlying
> > > CONSTRUCTOR as fast as before.
> > 
> > Also, with this patch, I'm not totally sure but I think we might not
> > need the special preeval handling in cxx_eval_store_expression anymore.
> > I could try to remove it in a subsequent patch.
> 
> I think for C++17 order of evaluation it's better to keep preevaluating when
> we can.

Sounds good.

> 
> > > gcc/cp/ChangeLog:
> > > 
> > >   PR c++/94205
> > >   PR c++/94219
> > >   * constexpr.c (get_or_insert_ctor_field): Split out (while adding
> > >   support for VECTOR_TYPEs, and optimizations for the common case)
> > >   from ...
> > >   (cxx_eval_store_expression): ... here.  Rename local variable
> > >   'changed_active_union_member_p' to 'activated_union_member_p'.  Record
> > >   the sequence of indexes into 'indexes' that yields the subobject we're
> > >   assigning to.  Record the integer offsets of the constructor indexes
> > >   we're assigning through into 'index_pos_hints'.  After evaluating the
> > >   initializer of the store expression, recompute 'valp' using 'indexes'
> > >   and 'index_pos_hints' as hints.
> > >   (cxx_eval_bare_aggregate): Tweak comments.  Use
> > > get_or_insert_ctor_field
> > >   to recompute the pointer to the constructor_elt we're assigning
> > > through
> > >   after evaluating each initializer.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   PR c++/94205
> > >   PR c++/94219
> > >   * g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
> > >   * g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
> > >   * g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
> > >   * g++.dg/cpp1z/lambda-this5.C: New test.
> > > ---
> > >   gcc/cp/constexpr.c| 252 +++---
> > >   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C |  19 ++
> > >   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C |  21 ++
> > >   gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C |  22 ++
> > >   gcc/testsuite/g++.dg/cpp1z/lambda-this5.C |  11 +
> > >   5 files changed, 228 insertions(+), 97 deletions(-)
> > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C
> > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C
> > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C
> > >   create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this5.C
> > > 
> > > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > > index 91f0c3ba269..b4173c595f0 100644
> > > --- a/gcc/cp/constexpr.c
> > > +++ b/gcc/cp/constexpr.c
> > > @@ -3151,6 +3151,97 @@ find_array_ctor_elt (tree ary, tree dindex, bool
> > > insert)
> > > return -1;
> > >   }
> > >   +/* Return a pointer to the constructor_elt of CTOR which matches INDEX.
> > > If no
> > > +   matching constructor_elt exists, then add one to CTOR.
> > > +
> > > +   As an optimization, if POS_HINT is non-negative then it is used as a
> > > guess
> > > +   for the (integer) index of the matching constructor_elt within CTOR.
> > > */
> > > +
> > > +static constructor_elt *
> > > +get_or_insert_ctor_field (tree ctor, tree index, int pos_hint)
> > > +{
> > > +  tree type = TREE_TYPE (ctor);
> > > +  if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
> > > +{
> > > +  CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
> > > +  return _ELTS (ctor)->last();
> > > +}
> > > +  else if (TREE_CODE (type) == ARRAY_TYPE || TREE_CODE (type) ==
> > > VECTOR_TYPE)
> > > +{
> > > +  HOST_WIDE_INT i = find_array_ctor_elt (ctor, index,
> > > /*insert*/true);
> > > +  gcc_assert (i >= 0);
> > > +  constructor_elt *cep = CONSTRUCTOR_ELT (ctor, i);
> > > +  gcc_assert (cep->index == NULL_TREE
> > > +   || TREE_CODE (cep->index) != RANGE_EXPR);
> > > +  return cep;
> > > +}
> > > +  else
> > > +{
> > > +  gcc_assert (TREE_CODE (index) == FIELD_DECL);
> > > +
> > > +  /* We must keep the CONSTRUCTOR's ELTS in FIELD order.
> > > +  Usually we meet initializers in that order, but it is
> > > +  possible for base types to be placed not in program
> > > +  order.  

[PATCH v2] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
On Fri, Apr 03, 2020 at 03:02:58PM -0400, Jason Merrill via Gcc-patches wrote:
> > Or do we want a further wrapper, perhaps C++ FE only, that would do this
> > protected_set_expr_location_if_unset (stmt, locus)?
> 
> That sounds good to me.

So like this if it passes bootstrap/regtest?

2020-04-03  Jakub Jelinek  

PR debug/94441
* tree-iterator.h (expr_single): Declare.
* tree-iterator.c (expr_single): New function.
* tree.h (protected_set_expr_location_if_unset): Declare.
* tree.c (protected_set_expr_location): Use expr_single.
(protected_set_expr_location_if_unset): New function.

* parser.c (cp_parser_omp_for_loop): Use
protected_set_expr_location_if_unset.
* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.

* g++.dg/opt/pr94441.C: New test.

--- gcc/tree-iterator.h.jj  2020-04-02 12:53:41.556232418 +0200
+++ gcc/tree-iterator.h 2020-04-03 21:07:01.335933695 +0200
@@ -119,5 +119,6 @@ extern void append_to_statement_list (tr
 extern void append_to_statement_list_force (tree, tree *);
 extern tree expr_first (tree);
 extern tree expr_last (tree);
+extern tree expr_single (tree);
 
 #endif /* GCC_TREE_ITERATOR_H  */
--- gcc/tree-iterator.c.jj  2020-04-02 12:53:41.555232434 +0200
+++ gcc/tree-iterator.c 2020-04-03 21:07:01.335933695 +0200
@@ -354,4 +354,45 @@ expr_last (tree expr)
   return expr;
 }
 
+/* If EXPR is a STATEMENT_LIST containing just DEBUG_BEGIN_STMTs and
+   a single other stmt, return that other stmt (recursively).
+   If it is a STATEMENT_LIST containing no non-DEBUG_BEGIN_STMTs or
+   multiple, return NULL_TREE.
+   Otherwise return EXPR.  */
+
+tree
+expr_single (tree expr)
+{
+  if (expr == NULL_TREE)
+return expr;
+
+  if (TREE_CODE (expr) == STATEMENT_LIST)
+{
+  /* With -gstatement-frontiers we could have a STATEMENT_LIST with
+DEBUG_BEGIN_STMT(s) and only a single other stmt, which with
+-g wouldn't be present and we'd have that single other stmt
+directly instead.  */
+  struct tree_statement_list_node *n = STATEMENT_LIST_HEAD (expr);
+  if (!n)
+   return NULL_TREE;
+  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT)
+   {
+ n = n->next;
+ if (!n)
+   return NULL_TREE;
+   }
+  expr = n->stmt;
+  do
+   {
+ n = n->next;
+ if (!n)
+   return expr_single (expr);
+   }
+  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT);
+  return NULL_TREE;
+}
+
+  return expr;
+}
+
 #include "gt-tree-iterator.h"
--- gcc/tree.h.jj   2020-01-31 19:18:02.643900799 +0100
+++ gcc/tree.h  2020-04-03 21:09:26.134805791 +0200
@@ -1203,6 +1203,7 @@ get_expr_source_range (tree expr)
 }
 
 extern void protected_set_expr_location (tree, location_t);
+extern void protected_set_expr_location_if_unset (tree, location_t);
 
 extern tree maybe_wrap_with_location (tree, location_t);
 
--- gcc/tree.c.jj   2020-04-03 15:41:34.442645256 +0200
+++ gcc/tree.c  2020-04-03 21:08:57.47740 +0200
@@ -5148,33 +5148,23 @@ protected_set_expr_location (tree t, loc
 SET_EXPR_LOCATION (t, loc);
   else if (t && TREE_CODE (t) == STATEMENT_LIST)
 {
-  /* With -gstatement-frontiers we could have a STATEMENT_LIST with
-DEBUG_BEGIN_STMT(s) and only a single other stmt, which with
--g wouldn't be present and we'd have that single other stmt
-directly instead.  */
-  struct tree_statement_list_node *n = STATEMENT_LIST_HEAD (t);
-  if (!n)
-   return;
-  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT)
-   {
- n = n->next;
- if (!n)
-   return;
-   }
-  tree t2 = n->stmt;
-  do
-   {
- n = n->next;
- if (!n)
-   {
- protected_set_expr_location (t2, loc);
- return;
-   }
-   }
-  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT);
+  t = expr_single (t);
+  if (t && CAN_HAVE_LOCATION_P (t))
+   SET_EXPR_LOCATION (t, loc);
 }
 }
 
+/* Like PROTECTED_SET_EXPR_LOCATION, but only do that if T has
+   UNKNOWN_LOCATION.  */
+
+void
+protected_set_expr_location_if_unset (tree t, location_t loc)
+{
+  t = expr_single (t);
+  if (t && !EXPR_HAS_LOCATION (t))
+protected_set_expr_location (t, loc);
+}
+
 /* Data used when collecting DECLs and TYPEs for language data removal.  */
 
 class free_lang_data_d
--- gcc/cp/parser.c.jj  2020-04-02 12:53:41.542232631 +0200
+++ gcc/cp/parser.c 2020-04-03 21:11:39.675843324 +0200
@@ -39149,8 +39149,7 @@ cp_parser_omp_for_loop (cp_parser *parse
incr = cp_parser_omp_for_incr (parser, real_decl);
  else
incr = cp_parser_expression (parser);
- if (!EXPR_HAS_LOCATION (incr))
-   protected_set_expr_location (incr, input_location);
+ protected_set_expr_location_if_unset (incr, input_location);
}
 
 parse_close_paren:
--- 

Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

2020-04-03 Thread Patrick Palka via Gcc-patches
On Fri, 3 Apr 2020, Jason Merrill wrote:

> On 4/2/20 7:40 PM, Patrick Palka wrote:
> > +  /* Prefer the outermost matching object, but don't cross
> > + CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.  */
> > +  if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor))
> > +if (tree parent_ob = lookup_placeholder (ctx->parent, lval, type))
> > +  return parent_ob;
> 
> Instead of recursing here, would it work to replace the loop at the end with
> tail recursion?

Do you mean something like the following?

  static tree
  lookup_placeholder (const constexpr_ctx *ctx, bool lval, tree type)
  {
if (!ctx)
  return NULL_TREE;

tree ob = ctx->object;
if (ob && same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (ob), type))
  return obj;
else if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor))
  return lookup_placeholder (ctx->parent, lval, type);
else
  return NULL_TREE;
  }

I think we would need to set ctx->parent in more places in order for this to
work, so that each node in the path to the innermost suboject is represented by
a constexpr_ctx.

Besides that, using tail recursion would, IIUC, mean that we would return the
innermost matching object, but I think we want to return the outermost matching
object (without crossing CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors) when
there might be more than one matching object.  For if a PLACEHOLDER_EXPR really
was meant to refer to an object other than this outermost object, then
presumably the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag would have already been
set on some suboject constructor and so we wouldn't have recursed to
this outermost object in the first place, if I'm understanding the flag
correctly.



Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/2/20 2:19 PM, Patrick Palka wrote:

On Thu, 2 Apr 2020, Patrick Palka wrote:


This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR.  Evaluation of the initializer could add new elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers to
or assumptions about the CONSTRUCTOR's elements, and so these routines should be
prepared for that.

To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the pointer to the constructor_elt's through
which we're assigning, after it evaluates the initializer.  Care is taken to
to make the common case where the initializer does not modify the underlying
CONSTRUCTOR as fast as before.


Also, with this patch, I'm not totally sure but I think we might not
need the special preeval handling in cxx_eval_store_expression anymore.
I could try to remove it in a subsequent patch.


I think for C++17 order of evaluation it's better to keep preevaluating 
when we can.



gcc/cp/ChangeLog:

PR c++/94205
PR c++/94219
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
support for VECTOR_TYPEs, and optimizations for the common case)
from ...
(cxx_eval_store_expression): ... here.  Rename local variable
'changed_active_union_member_p' to 'activated_union_member_p'.  Record
the sequence of indexes into 'indexes' that yields the subobject we're
assigning to.  Record the integer offsets of the constructor indexes
we're assigning through into 'index_pos_hints'.  After evaluating the
initializer of the store expression, recompute 'valp' using 'indexes'
and 'index_pos_hints' as hints.
(cxx_eval_bare_aggregate): Tweak comments.  Use get_or_insert_ctor_field
to recompute the pointer to the constructor_elt we're assigning through
after evaluating each initializer.

gcc/testsuite/ChangeLog:

PR c++/94205
PR c++/94219
* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
* g++.dg/cpp1z/lambda-this5.C: New test.
---
  gcc/cp/constexpr.c| 252 +++---
  gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C |  19 ++
  gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C |  21 ++
  gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C |  22 ++
  gcc/testsuite/g++.dg/cpp1z/lambda-this5.C |  11 +
  5 files changed, 228 insertions(+), 97 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi3.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi4.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi5.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this5.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 91f0c3ba269..b4173c595f0 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3151,6 +3151,97 @@ find_array_ctor_elt (tree ary, tree dindex, bool insert)
return -1;
  }
  
+/* Return a pointer to the constructor_elt of CTOR which matches INDEX.  If no

+   matching constructor_elt exists, then add one to CTOR.
+
+   As an optimization, if POS_HINT is non-negative then it is used as a guess
+   for the (integer) index of the matching constructor_elt within CTOR.  */
+
+static constructor_elt *
+get_or_insert_ctor_field (tree ctor, tree index, int pos_hint)
+{
+  tree type = TREE_TYPE (ctor);
+  if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
+{
+  CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
+  return _ELTS (ctor)->last();
+}
+  else if (TREE_CODE (type) == ARRAY_TYPE || TREE_CODE (type) == VECTOR_TYPE)
+{
+  HOST_WIDE_INT i = find_array_ctor_elt (ctor, index, /*insert*/true);
+  gcc_assert (i >= 0);
+  constructor_elt *cep = CONSTRUCTOR_ELT (ctor, i);
+  gcc_assert (cep->index == NULL_TREE
+ || TREE_CODE (cep->index) != RANGE_EXPR);
+  return cep;
+}
+  else
+{
+  gcc_assert (TREE_CODE (index) == FIELD_DECL);
+
+  /* We must keep the CONSTRUCTOR's ELTS in FIELD order.
+Usually we meet initializers in that order, but it is
+possible for base types to be placed not in program
+order.  */
+  tree fields = TYPE_FIELDS (DECL_CONTEXT (index));
+  unsigned HOST_WIDE_INT idx = 0;
+  constructor_elt *cep = NULL;
+
+  /* First, check if we're changing the active member of a union.  */
+  if (TREE_CODE (type) == UNION_TYPE && CONSTRUCTOR_NELTS (ctor)
+ && CONSTRUCTOR_ELT (ctor, 0)->index != index)
+   vec_safe_truncate (CONSTRUCTOR_ELTS (ctor), 0);
+  /* Next, check the hint.  */
+  else if (pos_hint >= 0 && (unsigned)pos_hint < CONSTRUCTOR_NELTS (ctor)
+  && CONSTRUCTOR_ELT (ctor, 

[PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

2020-04-03 Thread Qing Zhao via Gcc-patches
Hi, David and Jakub,

Per the discussion we had for PR94230: provide an option to change the size 
limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 


I come up with the following simple patch per David’s suggestion:

Provide a new first class option -flocation-ranges to control enabling/disablng 
range tracking when recording source locations.
The default value for this option is enabling the range tracking.

When specify -fno-location-ranges, disable the range tracking to save space for 
column tracking. 

I have tested this GCC to build our huge application by adding 
-fno-location-ranges, the whole build completed without any issue. and
-Wmisleading-indent also emitted several helpful warning message during 
building.

I am running bootstrap right now.

Could you please take a look at the attached patch?

thanks.

Qing






Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/2/20 7:40 PM, Patrick Palka wrote:

+  /* Prefer the outermost matching object, but don't cross
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.  */
+  if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ctx->ctor))
+if (tree parent_ob = lookup_placeholder (ctx->parent, lval, type))
+  return parent_ob;


Instead of recursing here, would it work to replace the loop at the end 
with tail recursion?


Jason



Re: [PATCH] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 4/2/20 3:48 AM, Jakub Jelinek wrote:

Hi!

My recent protected_set_expr_location changes work well when
that function is called unconditionally, but as the testcase shows, the C++
FE has a few spots that do:
   if (!EXPR_HAS_LOCATION (stmt))
 protected_set_expr_location (stmt, locus);
or similar.  Now, if we have for -g0 stmt of some expression that can
have location and has != UNKNOWN_LOCATION, while -g instead has
a STATEMENT_LIST containing some DEBUG_BEGIN_STMTs + that expression with
that location, we don't call protected_set_expr_location in the -g0 case,
but do call it in the -g case, because on the STATEMENT_LIST
!EXPR_HAS_LOCATION.
The following patch introduces a helper function which digs up the single
expression of a STATEMENT_LIST and uses that expression in the
EXPR_HAS_LOCATION check (plus changes protected_set_expr_location to
also use that helper).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Or do we want a further wrapper, perhaps C++ FE only, that would do this
protected_set_expr_location_if_unset (stmt, locus)?


That sounds good to me.


2020-04-02  Jakub Jelinek  

PR debug/94441
* tree-iterator.h (expr_single): Declare.
* tree-iterator.c (expr_single): New function.
* tree.c (protected_set_expr_location): Use it.

* parser.c (cp_parser_omp_for_loop): Use expr_single.
* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.

* g++.dg/opt/pr94441.C: New test.

--- gcc/tree-iterator.h.jj  2020-01-12 11:54:38.497381967 +0100
+++ gcc/tree-iterator.h 2020-04-01 16:58:00.034347283 +0200
@@ -119,5 +119,6 @@ extern void append_to_statement_list (tr
  extern void append_to_statement_list_force (tree, tree *);
  extern tree expr_first (tree);
  extern tree expr_last (tree);
+extern tree expr_single (tree);
  
  #endif /* GCC_TREE_ITERATOR_H  */

--- gcc/tree-iterator.c.jj  2020-01-12 11:54:38.497381967 +0100
+++ gcc/tree-iterator.c 2020-04-01 17:05:23.388920122 +0200
@@ -354,4 +354,45 @@ expr_last (tree expr)
return expr;
  }
  
+/* If EXPR is a STATEMENT_LIST containing just DEBUG_BEGIN_STMTs and

+   a single other stmt, return that other stmt (recursively).
+   If it is a STATEMENT_LIST containing no non-DEBUG_BEGIN_STMTs or
+   multiple, return NULL_TREE.
+   Otherwise return EXPR.  */
+
+tree
+expr_single (tree expr)
+{
+  if (expr == NULL_TREE)
+return expr;
+
+  if (TREE_CODE (expr) == STATEMENT_LIST)
+{
+  /* With -gstatement-frontiers we could have a STATEMENT_LIST with
+DEBUG_BEGIN_STMT(s) and only a single other stmt, which with
+-g wouldn't be present and we'd have that single other stmt
+directly instead.  */
+  struct tree_statement_list_node *n = STATEMENT_LIST_HEAD (expr);
+  if (!n)
+   return NULL_TREE;
+  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT)
+   {
+ n = n->next;
+ if (!n)
+   return NULL_TREE;
+   }
+  expr = n->stmt;
+  do
+   {
+ n = n->next;
+ if (!n)
+   return expr_single (expr);
+   }
+  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT);
+  return NULL_TREE;
+}
+
+  return expr;
+}
+
  #include "gt-tree-iterator.h"
--- gcc/tree.c.jj   2020-03-26 10:35:29.984667559 +0100
+++ gcc/tree.c  2020-04-01 16:59:01.689453490 +0200
@@ -5148,30 +5148,9 @@ protected_set_expr_location (tree t, loc
  SET_EXPR_LOCATION (t, loc);
else if (t && TREE_CODE (t) == STATEMENT_LIST)
  {
-  /* With -gstatement-frontiers we could have a STATEMENT_LIST with
-DEBUG_BEGIN_STMT(s) and only a single other stmt, which with
--g wouldn't be present and we'd have that single other stmt
-directly instead.  */
-  struct tree_statement_list_node *n = STATEMENT_LIST_HEAD (t);
-  if (!n)
-   return;
-  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT)
-   {
- n = n->next;
- if (!n)
-   return;
-   }
-  tree t2 = n->stmt;
-  do
-   {
- n = n->next;
- if (!n)
-   {
- protected_set_expr_location (t2, loc);
- return;
-   }
-   }
-  while (TREE_CODE (n->stmt) == DEBUG_BEGIN_STMT);
+  t = expr_single (t);
+  if (t && CAN_HAVE_LOCATION_P (t))
+   SET_EXPR_LOCATION (t, loc);
  }
  }
  
--- gcc/cp/parser.c.jj	2020-03-29 11:14:41.087556278 +0200

+++ gcc/cp/parser.c 2020-04-01 17:03:00.730988186 +0200
@@ -39149,8 +39149,9 @@ cp_parser_omp_for_loop (cp_parser *parse
incr = cp_parser_omp_for_incr (parser, real_decl);
  else
incr = cp_parser_expression (parser);
- if (!EXPR_HAS_LOCATION (incr))
-   protected_set_expr_location (incr, input_location);
+ if (tree incrl = expr_single (incr))
+   if (!EXPR_HAS_LOCATION (incrl))
+ protected_set_expr_location (incrl, input_location);
}
  
  

Re: [PATCH] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

2020-04-03 Thread Jason Merrill via Gcc-patches

On 3/30/20 4:28 PM, Marek Polacek wrote:

Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:

   /* ??? Here's to hoping the front end fills in all of the indices,
  so we don't have to figure out what's missing ourselves.  */
   gcc_assert (purpose);

The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.  So
fill in the indexes manually, here we have an array, and we can simply
assign indexes starting from 0.

Bootstrapped/regtested on x86_64-linux, ok for trunk?


Shouldn't digest_init fill in the indexes?  In 
process_init_constructor_array I see


  if (!ce->index)
ce->index = size_int (i);


PR c++/94155 - crash in gimplifier with paren init of aggregates.
* decl.c (check_initializer): Fill in constructor indexes.

* g++.dg/cpp2a/paren-init22.C: New test.
---
  gcc/cp/decl.c |  6 ++
  gcc/testsuite/g++.dg/cpp2a/paren-init22.C | 15 +++
  2 files changed, 21 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init22.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 69a238997b4..80dd2d8b931 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6754,6 +6754,12 @@ check_initializer (tree decl, tree init, int flags, 
vec **cleanups)
  init = build_constructor_from_list (init_list_type_node, init);
  CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
  CONSTRUCTOR_IS_PAREN_INIT (init) = true;
+ /* The gimplifier expects that the front end fills in all of the
+indices.  Normally, reshape_init_array fills these in, but we
+don't call reshape_init because that does nothing when it gets
+CONSTRUCTOR_IS_PAREN_INIT.  */
+ for (unsigned int i = 0; i < CONSTRUCTOR_NELTS (init); i++)
+   CONSTRUCTOR_ELT (init, i)->index = size_int (i);
}
}
else if (TREE_CODE (init) == TREE_LIST
diff --git a/gcc/testsuite/g++.dg/cpp2a/paren-init22.C 
b/gcc/testsuite/g++.dg/cpp2a/paren-init22.C
new file mode 100644
index 000..1b2959e7731
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/paren-init22.C
@@ -0,0 +1,15 @@
+// PR c++/94155 - crash in gimplifier with paren init of aggregates.
+// { dg-do compile { target c++2a } }
+
+struct S { int i, j; };
+
+struct A {
+  S s;
+  constexpr A(S e) : s(e) {}
+};
+
+void
+f()
+{
+  A g[1]({{1, 1}});
+}

base-commit: 48e331d63827a0500670d685c0fe7d609e0a807a





[committed] Fix m32r target bug exposed by Jakub's cselib.c changes

2020-04-03 Thread Jeff Law via Gcc-patches

va-arg-22.c started failing on the m32r target (-O1 only) after Jakub's recent
cselib changes.

The m32r port has this pattern:

(define_insn "cpymemsi_internal"
  [(set (mem:BLK (match_operand:SI 0 "register_operand" "r"))   ;; destination
(mem:BLK (match_operand:SI 1 "register_operand" "r")))  ;; source
   (use (match_operand:SI 2 "m32r_block_immediate_operand" "J"));; # bytes to
move
   (set (match_operand:SI 3 "register_operand" "=0")
(plus:SI (minus (match_dup 2) (const_int 4))
 (match_dup 0)))
   (set (match_operand:SI 4 "register_operand" "=1")
(plus:SI (match_dup 1)
 (match_dup 2)))
   (clobber (match_scratch:SI 5 "="))  ;; temp1
   (clobber (match_scratch:SI 6 "="))] ;; temp2

Note how it updates operand0/operand3 and operand1/operand4.  In simplest terms
it adds the # bytes copied to each operand.

When we output the assembly code for the pattern it has some smarts to avoid
doing half-word and byte loads to handle residuals -- instead it loads a full
word.  That's all fine and good, except the loads occur with post-increment
addressing so after we're done with the actual memory copies the source pointer
can actually point 1, 2 or 3 bytes beyond where it should.  To compound the
problem we then incorrectly manually adjust the operand to account for residuals
resulting in the source pointer pointing 2, 4 or 6 bytes past where it should.

In va-arg-22.c, when compiled with -O1, it turns out we want to use the adjusted
source pointer in a subsequent insn.  AFAICT, cselib didn't discover the
equivalence before, but does so now and with the bugs in the m32r port noted
above the pointer has the wrong value and all hell breaks loose.

This patch fixes the assembly code we generate for cpymemsi_internal.  Naturally
this fixes va-arg-22.c at -O1.  It doesn't fix any of the other long standing
failures though.

Committing to the trunk,

Jeff
commit b949f8e2acb49273b2f08ecaa3bc7128baaad850
Author: Jeff Law 
Date:   Fri Apr 3 12:46:13 2020 -0600

Fix va-arg-22.c at -O1 on m32r.

PR rtl-optimization/92264
* config/m32r/m32r.c (m32r_output_block_move): Properly account for
post-increment addressing of source operands as well as residuals
when computing any adjustments to the input pointer.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7083bbb9cce..e9dfa71ec0e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-04-03  Jeff Law  
+
+   PR rtl-optimization/92264
+   * config/m32r/m32r.c (m32r_output_block_move): Properly account for
+   post-increment addressing of source operands as well as residuals
+   when computing any adjustments to the input pointer.
+
 2020-04-03  Jakub Jelinek  
 
PR target/94460
diff --git a/gcc/config/m32r/m32r.c b/gcc/config/m32r/m32r.c
index 1c015609524..27fb495ed17 100644
--- a/gcc/config/m32r/m32r.c
+++ b/gcc/config/m32r/m32r.c
@@ -2676,7 +2676,7 @@ m32r_output_block_move (rtx insn ATTRIBUTE_UNUSED, rtx 
operands[])
 destination pointer.  */
  int dst_inc_amount = dst_offset + bytes - 4;
  /* The same for the source pointer.  */
- int src_inc_amount = bytes;
+ int src_inc_amount = bytes - (got_extra ? 4 : 0);
  int last_shift;
  rtx my_operands[3];
 


Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

2020-04-03 Thread Egeyar Bagcioglu via Gcc-patches



On 3/18/20 10:05 AM, Martin Liška wrote:

On 3/17/20 7:43 PM, Egeyar Bagcioglu wrote:

Hi Martin,

I like the patch. It definitely serves our purposes at Oracle and 
provides another way to do what my previous patches did as well.


1) It keeps the backwards compatibility regarding 
-frecord-gcc-switches; therefore, removes my related doubts about 
your previous patch.


2) It still makes use of -frecord-gcc-switches. The new option is 
only to control the format. This addresses some previous objections 
to having a new option doing something similar. Now the new option 
controls the behaviour of the existing one and that behaviour can be 
further extended.


3) It uses an environment variable as Jakub suggested.

The patch looks good and I confirm that it works for our purposes.


Hello.

Thank you for the support.



Having said that, I have to ask for recognition in this patch for my 
and my company's contributions. Can you please keep my name and my 
work email in the changelog and in the commit message?


Sure, sorry I forgot.


Hi Martin,

I noticed that some comments in the patch were still referring to 
--record-gcc-command-line, the option I suggested earlier. I updated 
those comments to mention -frecord-gcc-switches-format instead and also 
added my name to the patch as you agreed above. I attached the updated 
patch. We are starting to use this patch in the specific domain where we 
need its functionality.


Regards
Egeyar




Martin



Thanks
Egeyar



On 3/17/20 2:53 PM, Martin Liška wrote:

Hi.

I'm sending enhanced patch that makes the following changes:
- a new option -frecord-gcc-switches-format is added; the option
  selects format (processed, driver) for all options that record
  GCC command line
- Dwarf gen_produce_string is now used in -fverbose-asm
- The .s file is affected in the following way:

BEFORE:

# GNU C17 (SUSE Linux) version 9.2.1 20200128 [revision 
83f65674e78d97d27537361de1a9d74067ff228d] (x86_64-suse-linux)
#    compiled by GNU C version 9.2.1 20200128 [revision 
83f65674e78d97d27537361de1a9d74067ff228d], GMP version 6.2.0, MPFR 
version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP


# GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072

# options passed:  -fpreprocessed test.i -march=znver1 -mmmx -mno-3dnow
# -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha
# -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi 
-mno-sgx
# -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 
-msse4.1

# -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw
# -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er 
-mno-avx512cd

# -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves
# -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma 
-mno-avx512vbmi
# -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero 
-mno-pku

# -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni
# -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri 
-mno-movdir64b

# -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32
# --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver1
# -grecord-gcc-switches -g -fverbose-asm -frecord-gcc-switches
# options enabled:  -faggressive-loop-optimizations -fassume-phsa
# -fasynchronous-unwind-tables -fauto-inc-dec -fcommon
# -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining
# -feliminate-unused-debug-types -ffp-int-builtin-inexact 
-ffunction-cse

# -fgcse-lm -fgnu-runtime -fgnu-unique -fident -finline-atomics
# -fipa-stack-alignment -fira-hoist-pressure -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -flifetime-dse -flto-odr-type-merging 
-fmath-errno

# -fmerge-debug-strings -fpeephole -fplt -fprefetch-loop-arrays
# -frecord-gcc-switches -freg-struct-return 
-fsched-critical-path-heuristic
# -fsched-dep-count-heuristic -fsched-group-heuristic 
-fsched-interblock

# -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
# -fsched-spec-insn-heuristic -fsched-stalled-insns-dep 
-fschedule-fusion

# -fsemantic-interposition -fshow-column -fshrink-wrap-separate
# -fsigned-zeros -fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt
# -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math 
-ftree-cselim
# -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im 
-ftree-loop-ivcanon

# -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop
# -ftree-reassoc -ftree-scev-cprop -funit-at-a-time -funwind-tables
# -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m64 
-m80387

# -mabm -madx -maes -malign-stringops -mavx -mavx2
# -mavx256-split-unaligned-store -mbmi -mbmi2 -mclflushopt -mclzero 
-mcx16
# -mf16c -mfancy-math-387 -mfma -mfp-ret-in-387 -mfsgsbase -mfxsr 
-mglibc

# -mieee-fp -mlong-double-80 -mlzcnt -mmmx -mmovbe -mmwaitx -mpclmul
# -mpopcnt -mprfchw -mpush-args -mrdrnd -mrdseed -mred-zone -msahf 
-msha

# -msse 

Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

2020-04-03 Thread Joseph Myers
Thanks, this matches the commit hook (which only rejects From-SVN: at 
start of line, not elsewhere in a commit message).

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


Re: [PATCH] i386: Fix up handling of OPTION_MASK_ISA_MMX builtins [PR94461]

2020-04-03 Thread Uros Bizjak via Gcc-patches
On Fri, Apr 3, 2020 at 7:30 PM Jakub Jelinek  wrote:
>
> Hi!
>
> In https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00576.html the builtin
> handling was changed so that OPTION_MASK_ISA_MMX | OPTION_MASK_ISA_SSE
> etc. in i386-builtin.def means we require both mmx and sse, not just one of
> those, and later on for other option combinations very similar rule has
> been clarified, with a few exceptions that ix86_expand_builtin lists
> (SSE | 3DNOW_A, SSE4_2 | CRC32 and FMA | FMA4 are one or the other).
> The above mentioned patch also added OPTION_MASK_ISA_MMX to a few insns
> that in the ISA documents are documented e.g. only requiring SSE2 or SSSE3
> etc. CPUID, but because those builtins take or return V2SI or similar
> MMX-ish arguments, we can't really support those builtins in functions that
> have MMX disabled.
> Now, during the TARGET_MMX_WITH_SSE changes,
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01479.html
> and
> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01084.html
> actually changed this; it added | OPTION_MASK_ISA_SSE2 to builtins
> that were formerly OPTION_MASK_ISA_MMX only, but didn't touch the builtins
> that were already using OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX
> for something different (both options must be enabled).
> This causes e.g. ICE on the following testcase, because the builtins are
> now enabled even with just -mmmx -mno-sse2, even when they (those changed in
> 2017) require SSE2.
> The following patch instead reverts the above two 2019-ish changes (except
> for header/testsuite changes), and instead treats OPTION_MASK_ISA_MMX
> requirement in bdesc/.isa specially, as being satisfied by either
> TARGET_MMX (no changes really needed for that), or by TARGET_MMX_WITH_SSE.
> This achieves what the two 2019-ish patches want to do, that the
> OPTION_MASK_ISA_MMX only builtins are enabled not just with -mmmx, but also
> with -m64 -msse2, and for the other builtins that require MMX and something
> else will either require -mmmx and that some other ISA, or -m64 -msse2 and
> that other ISA, but -mmmx will not enable builtins that need something more
> than OPTION_MASK_ISA_MMX only.
> The i386-builtins.c changes that aren't reversion of the two patches try to
> make sure that in .isa we still record OPTION_MASK_ISA_MMX for builtins that
> have that requirement, so that it is in the end only ix86_expand_builtin
> that decides if the builtin is ok or not and the rest of code just decides
> if it is the right time to declare the builtin already or if it should be
> deferred.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-04-03  Jakub Jelinek  
>
> PR target/94461
> * config/i386/i386-expand.c (ix86_expand_builtin): If
> TARGET_MMX_WITH_SSE without TARGET_MMX and bisa contains
> OPTION_MASK_ISA_MMX, clear OPTION_MASK_ISA_MMX and set
> OPTION_MASK_ISA_SSE2 in bisa.  Revert 2019-05-17 and 2019-05-15
> changes.
> * config/i386/i386-builtins.c (def_builtin): If mask includes
> OPTION_MASK_ISA_MMX and TARGET_MMX_WITH_SSE, consider it satisfied.
> (ix86_add_new_builtins): For TARGET_64BIT, consider
> OPTION_MASK_ISA_SSE2 enabled in isa as satisfying OPTION_MASK_ISA_MMX
> requirement.
> (ix86_init_tm_builtins): If TARGET_MMX_WITH_SSE consider
> OPTION_MASK_ISA_MMX as satisfied.
> (bdesc_tm): Revert 2019-05-15 changes.
> (ix86_init_mmx_sse_builtins): Likewise.
> * config/i386/i386-builtin.def: Likewise.
>
> * gcc.target/i386/pr94461.c: New test.

LGTM (following the logic through the code literally gave me a
headache) since you know .isa recording stuff better than I.

Please note the comment in the testcase.

Thanks,
Uros.

> --- gcc/config/i386/i386-expand.c.jj2020-04-03 15:41:29.246722608 +0200
> +++ gcc/config/i386/i386-expand.c   2020-04-03 15:42:17.588002941 +0200
> @@ -10968,8 +10968,9 @@ ix86_expand_builtin (tree exp, rtx targe
>   OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A
>   OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_CRC32
>   OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4
> - where for each this pair it is sufficient if either of the ISAs is
> - enabled, plus if it is ored with other options also those others.  */
> + where for each such pair it is sufficient if either of the ISAs is
> + enabled, plus if it is ored with other options also those others.
> + OPTION_MASK_ISA_MMX in bisa is satisfied also if TARGET_MMX_WITH_SSE.  
> */
>if (((bisa & (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A))
> == (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A))
>&& (isa & (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A)) != 0)
> @@ -10982,24 +10983,10 @@ ix86_expand_builtin (tree exp, rtx targe
> == (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4))
>&& (isa & (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4)) != 0)
>  isa |= (OPTION_MASK_ISA_FMA | 

[pushed] c++: alias template and parameter packs (PR91966).

2020-04-03 Thread Jason Merrill via Gcc-patches
In this testcase, when we do a pack expansion of count_better_mins,
nums appears both in the definition of count_better_mins and as its template
argument.  The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>,   But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum...>, which never gives us less<2,7>.  We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog
2020-04-03  Jason Merrill  

PR c++/91966
* pt.c (complex_pack_expansion_r): New.
(complex_alias_template_p): Use it.
---
 gcc/cp/pt.c  |  31 +-
 gcc/testsuite/g++.dg/cpp0x/variadic-alias2.C | 103 +++
 2 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-alias2.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bd30c96a12a..b602f9f82c7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6351,6 +6351,33 @@ uses_all_template_parms_r (tree t, void *data_)
   return 0;
 }
 
+/* for_each_template_parm any_fn callback for complex_alias_template_p.  */
+
+static int
+complex_pack_expansion_r (tree t, void *data_)
+{
+  /* An alias template with a pack expansion that expands a pack from the
+ enclosing class needs to be considered complex, to avoid confusion with
+ the same pack being used as an argument to the alias's own template
+ parameter (91966).  */
+  if (!PACK_EXPANSION_P (t))
+return 0;
+  struct uses_all_template_parms_data 
+= *(struct uses_all_template_parms_data*)data_;
+  for (tree pack = PACK_EXPANSION_PARAMETER_PACKS (t); pack;
+   pack = TREE_CHAIN (pack))
+{
+  tree parm_pack = TREE_VALUE (pack);
+  if (!TEMPLATE_PARM_P (parm_pack))
+   continue;
+  int idx, level;
+  template_parm_level_and_index (parm_pack, , );
+  if (level < data.level)
+   return 1;
+}
+  return 0;
+}
+
 static bool
 complex_alias_template_p (const_tree tmpl)
 {
@@ -6371,7 +6398,9 @@ complex_alias_template_p (const_tree tmpl)
   for (int i = 0; i < len; ++i)
 data.seen[i] = false;
 
-  for_each_template_parm (pat, uses_all_template_parms_r, , NULL, true);
+  if (for_each_template_parm (pat, uses_all_template_parms_r, ,
+ NULL, true, complex_pack_expansion_r))
+return true;
   for (int i = 0; i < len; ++i)
 if (!data.seen[i])
   return true;
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-alias2.C 
b/gcc/testsuite/g++.dg/cpp0x/variadic-alias2.C
new file mode 100644
index 000..ab64866d35f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-alias2.C
@@ -0,0 +1,103 @@
+// PR c++/91966
+// { dg-do compile { target c++11 } }
+
+// Reduced to this include-free example. Further reduction is hard: Either
+// the bug(?) disappears, or the program becomes meaningless.
+
+template
+struct list {};
+
+struct nil;
+
+
+
+template
+struct number {
+  constexpr /*implicit*/ operator int() const { return n; }
+  using type = number;
+};
+
+using false_ = number<0>;
+using true_ = number<1>;
+
+static_assert(!false_{}, "");
+static_assert(true_{}, "");
+
+template using numbers = list...>;
+
+
+
+template
+struct less_impl;
+
+template
+struct less_impl, number>
+  : number<(lhs < rhs)> {};
+
+template using less = typename less_impl::type;
+
+
+
+template
+struct sum_impl {
+  static_assert(sizeof...(vs) == 0, "see specialization");
+  using type = v0;
+};
+
+template
+struct sum_impl, number, vs...>
+  : sum_impl, vs...> {};
+
+template using sum = typename sum_impl::type;
+
+
+
+template
+struct conditional_impl {
+  static_assert(num{}, "see specialization");
+
+  template
+  using type = T;
+};
+
+template<>
+struct conditional_impl {
+  template
+  using type = F;
+};
+
+template
+using conditional = typename conditional_impl::template type;
+
+
+
+template
+struct min_filter_impl;
+
+template
+struct min_filter_impl> {
+  template
+  using count_better_mins = sum...>;
+
+  using type = list, nil, nums>...>;
+
+//using debug = list, nil, void>...>;
+
+// error: expansion pattern 'conditional...>::type, nil, void>' contains no parameter packs
+
+};
+
+template using min_filter = typename min_filter_impl::type;
+
+
+

[PATCH] cselib: Don't consider SP_DERIVED_VALUE_P values as useless [PR94468]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase ICEs, because at one point we see the
SP_DERIVED_VALUE_P VALUE as useless (not PRESERVED_VALUE_P and no locs)
and so expect it to be discarded as useless.  But, later on we
are adding some new VALUE that is equivalent to it, and when adding
the equivalency that that new VALUE is equal to this SP_DERIVED_VALUE_P,
new_elt_loc_list has code for VALUE canonicalization and reverses addition
if uid is smaller, and at that point a new loc is added to the
SP_DERIVED_VALUE_P VALUE and it isn't discarded as useless anymore.
Now, I think we don't want to discard the SP_DERIVED_VALUE_P values
even if they have no locs, because they still have the special behaviour
that they then force other new VALUEs to be canonicalized against them,
which is what this patch implements.  I've not set PRESERVED_VALUE_P
on the SP_DERIVED_VALUE_P at the creation time, because whether a VALUE
is preserved or not is something that affects var-tracking decisions quite a
lot and we shouldn't set it blindly on other VALUEs.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Or, to avoid the repetitive code, should I introduce
static bool
cselib_useless_value_p (cselib_val *v)
{
  return (v->locs == 0
  && !PRESERVED_VALUE_P (v->val_rtx)
  && !SP_DERIVED_VALUE_P (v->val_rtx)));
}
predicate and use it in those 6 spots?

2020-04-03  Jakub Jelinek  

PR rtl-optimization/94468
* cselib.c (references_value_p): Formatting fix.
(discard_useless_locs, discard_useless_values,
cselib_invalidate_regno_val, cselib_invalidate_mem,
cselib_record_set): Don't consider SP_DERIVED_VALUE_P values useless.

* g++.dg/opt/pr94468.C: New test.

--- gcc/cselib.c.jj 2020-04-02 14:28:02.620577679 +0200
+++ gcc/cselib.c2020-04-03 17:08:54.295282018 +0200
@@ -629,8 +629,8 @@ references_value_p (const_rtx x, int onl
   int i, j;
 
   if (GET_CODE (x) == VALUE
-  && (! only_useless ||
- (CSELIB_VAL_PTR (x)->locs == 0 && !PRESERVED_VALUE_P (x
+  && (! only_useless
+ || (CSELIB_VAL_PTR (x)->locs == 0 && !PRESERVED_VALUE_P (x
 return 1;
 
   for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
@@ -666,7 +666,10 @@ discard_useless_locs (cselib_val **x, vo
p = &(*p)->next;
 }
 
-  if (had_locs && v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (had_locs
+  && v->locs == 0
+  && !PRESERVED_VALUE_P (v->val_rtx)
+  && !SP_DERIVED_VALUE_P (v->val_rtx))
 {
   if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_debug_values++;
@@ -684,7 +687,9 @@ discard_useless_values (cselib_val **x,
 {
   cselib_val *v = *x;
 
-  if (v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (v->locs == 0
+  && !PRESERVED_VALUE_P (v->val_rtx)
+  && !SP_DERIVED_VALUE_P (v->val_rtx))
 {
   if (cselib_discard_hook)
cselib_discard_hook (v);
@@ -2370,7 +2375,10 @@ cselib_invalidate_regno_val (unsigned in
}
 }
 
-  if (had_locs && v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (had_locs
+  && v->locs == 0
+  && !PRESERVED_VALUE_P (v->val_rtx)
+  && !SP_DERIVED_VALUE_P (v->val_rtx))
 {
   if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_debug_values++;
@@ -2515,7 +2523,10 @@ cselib_invalidate_mem (rtx mem_rtx)
  unchain_one_elt_loc_list (p);
}
 
-  if (had_locs && v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx))
+  if (had_locs
+ && v->locs == 0
+ && !PRESERVED_VALUE_P (v->val_rtx)
+ && !SP_DERIVED_VALUE_P (v->val_rtx))
{
  if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_debug_values++;
@@ -2593,14 +2604,18 @@ cselib_record_set (rtx dest, cselib_val
  REG_VALUES (dreg)->elt = src_elt;
}
 
-  if (src_elt->locs == 0 && !PRESERVED_VALUE_P (src_elt->val_rtx))
+  if (src_elt->locs == 0
+ && !PRESERVED_VALUE_P (src_elt->val_rtx)
+ && !SP_DERIVED_VALUE_P (src_elt->val_rtx))
n_useless_values--;
   new_elt_loc_list (src_elt, dest);
 }
   else if (MEM_P (dest) && dest_addr_elt != 0
   && cselib_record_memory)
 {
-  if (src_elt->locs == 0 && !PRESERVED_VALUE_P (src_elt->val_rtx))
+  if (src_elt->locs == 0
+ && !PRESERVED_VALUE_P (src_elt->val_rtx)
+ && !SP_DERIVED_VALUE_P (src_elt->val_rtx))
n_useless_values--;
   add_mem_for_addr (dest_addr_elt, src_elt, dest);
 }
--- gcc/testsuite/g++.dg/opt/pr94468.C.jj   2020-04-03 17:16:38.804457422 
+0200
+++ gcc/testsuite/g++.dg/opt/pr94468.C  2020-04-03 17:16:18.450756522 +0200
@@ -0,0 +1,57 @@
+// PR rtl-optimization/94468
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2" }
+// { dg-additional-options "-fPIC" { target fpic } }
+
+bool a();
+enum b {};
+class c;
+template  struct d;
+template  struct d {
+  typedef e i;
+};
+struct j { j(void(int, j *, c *, void **, bool *)) {} };

[PATCH] i386: Fix up handling of OPTION_MASK_ISA_MMX builtins [PR94461]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
Hi!

In https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00576.html the builtin
handling was changed so that OPTION_MASK_ISA_MMX | OPTION_MASK_ISA_SSE
etc. in i386-builtin.def means we require both mmx and sse, not just one of
those, and later on for other option combinations very similar rule has
been clarified, with a few exceptions that ix86_expand_builtin lists
(SSE | 3DNOW_A, SSE4_2 | CRC32 and FMA | FMA4 are one or the other).
The above mentioned patch also added OPTION_MASK_ISA_MMX to a few insns
that in the ISA documents are documented e.g. only requiring SSE2 or SSSE3
etc. CPUID, but because those builtins take or return V2SI or similar
MMX-ish arguments, we can't really support those builtins in functions that
have MMX disabled.
Now, during the TARGET_MMX_WITH_SSE changes,
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01479.html
and
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01084.html
actually changed this; it added | OPTION_MASK_ISA_SSE2 to builtins
that were formerly OPTION_MASK_ISA_MMX only, but didn't touch the builtins
that were already using OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX
for something different (both options must be enabled).
This causes e.g. ICE on the following testcase, because the builtins are
now enabled even with just -mmmx -mno-sse2, even when they (those changed in
2017) require SSE2.
The following patch instead reverts the above two 2019-ish changes (except
for header/testsuite changes), and instead treats OPTION_MASK_ISA_MMX
requirement in bdesc/.isa specially, as being satisfied by either
TARGET_MMX (no changes really needed for that), or by TARGET_MMX_WITH_SSE.
This achieves what the two 2019-ish patches want to do, that the
OPTION_MASK_ISA_MMX only builtins are enabled not just with -mmmx, but also
with -m64 -msse2, and for the other builtins that require MMX and something
else will either require -mmmx and that some other ISA, or -m64 -msse2 and
that other ISA, but -mmmx will not enable builtins that need something more
than OPTION_MASK_ISA_MMX only.
The i386-builtins.c changes that aren't reversion of the two patches try to
make sure that in .isa we still record OPTION_MASK_ISA_MMX for builtins that
have that requirement, so that it is in the end only ix86_expand_builtin
that decides if the builtin is ok or not and the rest of code just decides
if it is the right time to declare the builtin already or if it should be
deferred.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-04-03  Jakub Jelinek  

PR target/94461
* config/i386/i386-expand.c (ix86_expand_builtin): If
TARGET_MMX_WITH_SSE without TARGET_MMX and bisa contains
OPTION_MASK_ISA_MMX, clear OPTION_MASK_ISA_MMX and set
OPTION_MASK_ISA_SSE2 in bisa.  Revert 2019-05-17 and 2019-05-15
changes.
* config/i386/i386-builtins.c (def_builtin): If mask includes
OPTION_MASK_ISA_MMX and TARGET_MMX_WITH_SSE, consider it satisfied.
(ix86_add_new_builtins): For TARGET_64BIT, consider
OPTION_MASK_ISA_SSE2 enabled in isa as satisfying OPTION_MASK_ISA_MMX
requirement.
(ix86_init_tm_builtins): If TARGET_MMX_WITH_SSE consider
OPTION_MASK_ISA_MMX as satisfied.
(bdesc_tm): Revert 2019-05-15 changes.
(ix86_init_mmx_sse_builtins): Likewise.
* config/i386/i386-builtin.def: Likewise.

* gcc.target/i386/pr94461.c: New test.

--- gcc/config/i386/i386-expand.c.jj2020-04-03 15:41:29.246722608 +0200
+++ gcc/config/i386/i386-expand.c   2020-04-03 15:42:17.588002941 +0200
@@ -10968,8 +10968,9 @@ ix86_expand_builtin (tree exp, rtx targe
  OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A
  OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_CRC32
  OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4
- where for each this pair it is sufficient if either of the ISAs is
- enabled, plus if it is ored with other options also those others.  */
+ where for each such pair it is sufficient if either of the ISAs is
+ enabled, plus if it is ored with other options also those others.
+ OPTION_MASK_ISA_MMX in bisa is satisfied also if TARGET_MMX_WITH_SSE.  */
   if (((bisa & (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A))
== (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A))
   && (isa & (OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_3DNOW_A)) != 0)
@@ -10982,24 +10983,10 @@ ix86_expand_builtin (tree exp, rtx targe
== (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4))
   && (isa & (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4)) != 0)
 isa |= (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_FMA4);
-  /* Use SSE/SSE2/SSSE3 to emulate MMX intrinsics in 64-bit mode when
- MMX is disabled.  NB: Since MMX intrinsics are marked with
- SSE/SSE2/SSSE3, enable them without SSE/SSE2/SSSE3 if MMX is
- enabled.  */
-  if (TARGET_MMX || TARGET_MMX_WITH_SSE)
+  if ((bisa & OPTION_MASK_ISA_MMX) && !TARGET_MMX && TARGET_MMX_WITH_SSE)
 {
-  if (((bisa & 

Re: [PATCH] i386: Fix vph{add, subs?}[wd] 256-bit AVX2 RTL patterns [PR94460]

2020-04-03 Thread Uros Bizjak via Gcc-patches
On Fri, Apr 3, 2020 at 7:06 PM Jakub Jelinek  wrote:
>
> Hi!
>
> The following testcase is miscompiled, because the AVX2 patterns don't
> describe correctly what the insn does.  E.g. vphaddd with %ymm* operands
> (the second pattern) instruction as per:
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32=2941
> does { a0+a1, a2+a3, b0+b1, b2+b3, a4+a5, a6+a7, b4+b5, b6+b7 }
> but our RTL pattern did
>  { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7 }
> where the first and last 64 bits are the same and two middle 64 bits
> swapped.
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi16=2939
> similarly, insn does:
>  { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7,
>a8+a9, a10+a11, a12+a13, a14+a15, b8+b9, b10+b11, b12+b13, b14+b15 }
> but RTL pattern did
>  { a0+a1, a2+a3, a4+a5, a6+a7, a8+a9, a10+a11, a12+a13, a14+a15,
>b0+b1, b2+b3, b4+b5, b6+b7, b8+b9, b10+b11, b12+b13, b14+b15 }
> again, first and last 64 bits are the same and the two middle 64 bits
> swapped.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> As a follow-up for GCC11, I have simplification for the patterns.
>
> 2020-04-03  Jakub Jelinek  
>
> PR target/94460
> * config/i386/sse.md (avx2_phwv16hi3,
> avx2_phdv8si3): Fix up RTL pattern to do
> second half of first lane from first lane of second operand and
> first half of second lane from second lane of first operand.
>
> * gcc.target/i386/avx2-pr94460.c: New test.

OK for trunk and backports.

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2020-03-30 18:04:31.942435289 +0200
> +++ gcc/config/i386/sse.md  2020-04-03 10:21:51.110564277 +0200
> @@ -16060,22 +16060,6 @@ (define_insn "avx2_ph (vec_concat:V4HI
>   (vec_concat:V2HI
> (ssse3_plusminus:HI
> - (vec_select:HI (match_dup 1) (parallel [(const_int 8)]))
> - (vec_select:HI (match_dup 1) (parallel [(const_int 9)])))
> -   (ssse3_plusminus:HI
> - (vec_select:HI (match_dup 1) (parallel [(const_int 10)]))
> - (vec_select:HI (match_dup 1) (parallel [(const_int 11)]
> - (vec_concat:V2HI
> -   (ssse3_plusminus:HI
> - (vec_select:HI (match_dup 1) (parallel [(const_int 12)]))
> - (vec_select:HI (match_dup 1) (parallel [(const_int 13)])))
> -   (ssse3_plusminus:HI
> - (vec_select:HI (match_dup 1) (parallel [(const_int 14)]))
> - (vec_select:HI (match_dup 1) (parallel [(const_int 
> 15)]))
> - (vec_concat:V8HI
> -   (vec_concat:V4HI
> - (vec_concat:V2HI
> -   (ssse3_plusminus:HI
>   (vec_select:HI
> (match_operand:V16HI 2 "nonimmediate_operand" "xm")
> (parallel [(const_int 0)]))
> @@ -16089,7 +16073,23 @@ (define_insn "avx2_ph   (vec_select:HI (match_dup 2) (parallel [(const_int 5)])))
> (ssse3_plusminus:HI
>   (vec_select:HI (match_dup 2) (parallel [(const_int 6)]))
> - (vec_select:HI (match_dup 2) (parallel [(const_int 7)])
> + (vec_select:HI (match_dup 2) (parallel [(const_int 7)]))
> + (vec_concat:V8HI
> +   (vec_concat:V4HI
> + (vec_concat:V2HI
> +   (ssse3_plusminus:HI
> + (vec_select:HI (match_dup 1) (parallel [(const_int 8)]))
> + (vec_select:HI (match_dup 1) (parallel [(const_int 9)])))
> +   (ssse3_plusminus:HI
> + (vec_select:HI (match_dup 1) (parallel [(const_int 10)]))
> + (vec_select:HI (match_dup 1) (parallel [(const_int 11)]
> + (vec_concat:V2HI
> +   (ssse3_plusminus:HI
> + (vec_select:HI (match_dup 1) (parallel [(const_int 12)]))
> + (vec_select:HI (match_dup 1) (parallel [(const_int 13)])))
> +   (ssse3_plusminus:HI
> + (vec_select:HI (match_dup 1) (parallel [(const_int 14)]))
> + (vec_select:HI (match_dup 1) (parallel [(const_int 15)])
> (vec_concat:V4HI
>   (vec_concat:V2HI
> (ssse3_plusminus:HI
> @@ -16224,21 +16224,21 @@ (define_insn "avx2_ph (vec_select:SI (match_dup 1) (parallel [(const_int 3)]
> (vec_concat:V2SI
>   (plusminus:SI
> -   (vec_select:SI (match_dup 1) (parallel [(const_int 4)]))
> -   (vec_select:SI (match_dup 1) (parallel [(const_int 5)])))
> - (plusminus:SI
> -   (vec_select:SI (match_dup 1) (parallel [(const_int 6)]))
> -   (vec_select:SI (match_dup 1) (parallel [(const_int 7)])
> - (vec_concat:V4SI
> -   

[PATCH] i386: Fix vph{add,subs?}[wd] 256-bit AVX2 RTL patterns [PR94460]

2020-04-03 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase is miscompiled, because the AVX2 patterns don't
describe correctly what the insn does.  E.g. vphaddd with %ymm* operands
(the second pattern) instruction as per:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32=2941
does { a0+a1, a2+a3, b0+b1, b2+b3, a4+a5, a6+a7, b4+b5, b6+b7 }
but our RTL pattern did
 { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7 }
where the first and last 64 bits are the same and two middle 64 bits
swapped.
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi16=2939
similarly, insn does:
 { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7,
   a8+a9, a10+a11, a12+a13, a14+a15, b8+b9, b10+b11, b12+b13, b14+b15 }
but RTL pattern did
 { a0+a1, a2+a3, a4+a5, a6+a7, a8+a9, a10+a11, a12+a13, a14+a15,
   b0+b1, b2+b3, b4+b5, b6+b7, b8+b9, b10+b11, b12+b13, b14+b15 }
again, first and last 64 bits are the same and the two middle 64 bits
swapped.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

As a follow-up for GCC11, I have simplification for the patterns.

2020-04-03  Jakub Jelinek  

PR target/94460
* config/i386/sse.md (avx2_phwv16hi3,
avx2_phdv8si3): Fix up RTL pattern to do
second half of first lane from first lane of second operand and
first half of second lane from second lane of first operand.

* gcc.target/i386/avx2-pr94460.c: New test.

--- gcc/config/i386/sse.md.jj   2020-03-30 18:04:31.942435289 +0200
+++ gcc/config/i386/sse.md  2020-04-03 10:21:51.110564277 +0200
@@ -16060,22 +16060,6 @@ (define_insn "avx2_ph
+#include "avx2-check.h"
+
+typedef __int128 v2ti __attribute__ ((__vector_size__ (32)));
+
+static inline v2ti
+foo (__v16hi b)
+{
+  return (v2ti) _mm256_hsub_epi16 ((__m256i) b, (__m256i) b);
+}
+
+static inline v2ti
+bar (__v8si b)
+{
+  return (v2ti) _mm256_hsub_epi32 ((__m256i) b, (__m256i) b);
+}
+
+static void
+avx2_test (void)
+{
+  v2ti x = foo ((__v16hi) { 1 });
+  if (x[0] != ((__int128)1 << 64 | 1) || x[1] != 0)
+abort ();
+  x = bar ((__v8si) { 1 });
+  if (x[0] != ((__int128)1 << 64 | 1) || x[1] != 0)
+abort ();
+}

Jakub



Re: [PATCH] x86: Mark scratch operand in ssse3_pshufbv8qi3 as earlyclobber

2020-04-03 Thread Uros Bizjak via Gcc-patches
On Fri, Apr 3, 2020 at 6:51 PM H.J. Lu  wrote:
>
> commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979
> Author: H.J. Lu 
> Date:   Wed May 15 15:26:19 2019 +
>
> i386: Emulate MMX pshufb with SSE version
>
> has
>
> +(define_insn_and_split "ssse3_pshufbv8qi3"
> +  [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
> +  (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
> +   (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")]
> +  UNSPEC_PSHUFB))
> +   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]
>^^^  There are earlyclobber.
> +  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
> +  "@
> +   pshufb\t{%2, %0|%0, %2}
> +   #
> +   #"
> +  "TARGET_MMX_WITH_SSE && reload_completed"
> +  [(set (match_dup 3) (match_dup 5))
> +   (set (match_dup 3)
> +  (and:V4SI (match_dup 3) (match_dup 2)))
> +   (set (match_dup 0)
> +  (unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]
>
> If input register operand 2 is dead after this insn, RA may choose it
> as scratch operand.  Since it isn't marked as earlyclobber, operand 2
> becomes unused after split and then it gets optimized out.  Mark scratch
> operand as earlyclobber fixes the issue.
>
> OK for master if there are no regressions?
>
> H.J.
> --
> gcc/
>
> PR target/94467
> * config/i386/sse.md (ssse3_pshufbv8qi3): Mark scratch operand
> as earlyclobber.
>
> gcc/
>
> PR target/94467
> * testsuite/gcc.target/i386/pr94467-1.c: New test.
> * testsuite/gcc.target/i386/pr94467-2.c: Likewise.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/sse.md|  2 +-
>  gcc/testsuite/gcc.target/i386/pr94467-1.c | 40 +++
>  gcc/testsuite/gcc.target/i386/pr94467-2.c | 48 +++
>  3 files changed, 89 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr94467-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr94467-2.c
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index fba91b7369a..1de03a515d9 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -16695,7 +16695,7 @@ (define_insn_and_split "ssse3_pshufbv8qi3"
> (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
>   (match_operand:V8QI 2 "register_mmxmem_operand" 
> "ym,x,Yv")]
>  UNSPEC_PSHUFB))
> -   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]
> +   (clobber (match_scratch:V4SI 3 "=X,,"))]
>"(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
>"@
> pshufb\t{%2, %0|%0, %2}
> diff --git a/gcc/testsuite/gcc.target/i386/pr94467-1.c 
> b/gcc/testsuite/gcc.target/i386/pr94467-1.c
> new file mode 100644
> index 000..a51c3a8f5fe
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr94467-1.c
> @@ -0,0 +1,40 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx } */
> +/* { dg-options "-O -mavx" } */
> +
> +#include "avx-check.h"
> +
> +typedef char __attribute__ ((__vector_size__ (8))) v8qi;
> +typedef short __attribute__ ((__vector_size__ (8))) v4hi;
> +typedef int __attribute__ ((__vector_size__ (8))) v2si;
> +typedef long long __attribute__ ((__vector_size__ (8))) v1di;
> +typedef unsigned long long u64;
> +u64 k, c;
> +
> +v8qi g, h, p, q;
> +v4hi d, e, f, l, n, o;
> +v2si j;
> +
> +u64
> +foo (v4hi r)
> +{
> +  v8qi s;
> +  f = (v4hi) j;
> +  e = __builtin_ia32_psrlwi ((v4hi) k, c);
> +  s = __builtin_ia32_pavgb (h, h);
> +  n = __builtin_ia32_pabsw (f);
> +  o = __builtin_ia32_psubusw (n, l);
> +  p = __builtin_ia32_packsswb (r, o);
> +  q = __builtin_ia32_pshufb (p, s);
> +  g = __builtin_ia32_punpcklbw (q, (v8qi) r);
> +  d = r;
> +  return (u64) g + (u64) h + (u64) j;
> +}
> +
> +static void
> +avx_test (void)
> +{
> +  u64 x = foo ((v4hi) { 5 });
> +  if (x != 0x0005000500050505)
> +__builtin_abort ();
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr94467-2.c 
> b/gcc/testsuite/gcc.target/i386/pr94467-2.c
> new file mode 100644
> index 000..8128be325e4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr94467-2.c
> @@ -0,0 +1,48 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target ssse3 } */
> +/* { dg-options "-O -mssse3" } */
> +
> +#ifndef CHECK_H
> +#define CHECK_H "ssse3-check.h"
> +#endif
> +
> +#ifndef TEST
> +#define TEST ssse3_test
> +#endif
> +
> +#include CHECK_H
> +
> +typedef char __attribute__ ((__vector_size__ (8))) v8qi;
> +typedef short __attribute__ ((__vector_size__ (8))) v4hi;
> +typedef int __attribute__ ((__vector_size__ (8))) v2si;
> +typedef long long __attribute__ ((__vector_size__ (8))) v1di;
> +typedef unsigned long long u64;
> +u64 k, c;
> +
> +v8qi g, h, p, q;
> +v4hi d, e, f, l, n, o;
> +v2si j;
> +
> +u64
> +foo (v4hi r)
> +{
> +  v8qi s;
> +  f = (v4hi) j;
> +  e = __builtin_ia32_psrlwi ((v4hi) k, c);
> +  s = __builtin_ia32_pavgb (h, h);
> +  n = __builtin_ia32_pabsw (f);
> +  o = __builtin_ia32_psubusw 

[PATCH] x86: Mark scratch operand in ssse3_pshufbv8qi3 as earlyclobber

2020-04-03 Thread H.J. Lu via Gcc-patches
commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979
Author: H.J. Lu 
Date:   Wed May 15 15:26:19 2019 +

i386: Emulate MMX pshufb with SSE version

has

+(define_insn_and_split "ssse3_pshufbv8qi3"
+  [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
+  (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
+   (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")]
+  UNSPEC_PSHUFB))
+   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]
   ^^^  There are earlyclobber.
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
+  "@
+   pshufb\t{%2, %0|%0, %2}
+   #
+   #"
+  "TARGET_MMX_WITH_SSE && reload_completed"
+  [(set (match_dup 3) (match_dup 5))
+   (set (match_dup 3)
+  (and:V4SI (match_dup 3) (match_dup 2)))
+   (set (match_dup 0)
+  (unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]

If input register operand 2 is dead after this insn, RA may choose it
as scratch operand.  Since it isn't marked as earlyclobber, operand 2
becomes unused after split and then it gets optimized out.  Mark scratch
operand as earlyclobber fixes the issue.

OK for master if there are no regressions?

H.J.
--
gcc/

PR target/94467
* config/i386/sse.md (ssse3_pshufbv8qi3): Mark scratch operand
as earlyclobber.

gcc/

PR target/94467
* testsuite/gcc.target/i386/pr94467-1.c: New test.
* testsuite/gcc.target/i386/pr94467-2.c: Likewise.
---
 gcc/config/i386/sse.md|  2 +-
 gcc/testsuite/gcc.target/i386/pr94467-1.c | 40 +++
 gcc/testsuite/gcc.target/i386/pr94467-2.c | 48 +++
 3 files changed, 89 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr94467-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr94467-2.c

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index fba91b7369a..1de03a515d9 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -16695,7 +16695,7 @@ (define_insn_and_split "ssse3_pshufbv8qi3"
(unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
  (match_operand:V8QI 2 "register_mmxmem_operand" 
"ym,x,Yv")]
 UNSPEC_PSHUFB))
-   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]
+   (clobber (match_scratch:V4SI 3 "=X,,"))]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
   "@
pshufb\t{%2, %0|%0, %2}
diff --git a/gcc/testsuite/gcc.target/i386/pr94467-1.c 
b/gcc/testsuite/gcc.target/i386/pr94467-1.c
new file mode 100644
index 000..a51c3a8f5fe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94467-1.c
@@ -0,0 +1,40 @@
+/* { dg-do run } */
+/* { dg-require-effective-target avx } */
+/* { dg-options "-O -mavx" } */
+
+#include "avx-check.h"
+
+typedef char __attribute__ ((__vector_size__ (8))) v8qi;
+typedef short __attribute__ ((__vector_size__ (8))) v4hi;
+typedef int __attribute__ ((__vector_size__ (8))) v2si;
+typedef long long __attribute__ ((__vector_size__ (8))) v1di;
+typedef unsigned long long u64;
+u64 k, c;
+
+v8qi g, h, p, q;
+v4hi d, e, f, l, n, o;
+v2si j;
+
+u64
+foo (v4hi r)
+{
+  v8qi s;
+  f = (v4hi) j;
+  e = __builtin_ia32_psrlwi ((v4hi) k, c);
+  s = __builtin_ia32_pavgb (h, h);
+  n = __builtin_ia32_pabsw (f);
+  o = __builtin_ia32_psubusw (n, l);
+  p = __builtin_ia32_packsswb (r, o);
+  q = __builtin_ia32_pshufb (p, s);
+  g = __builtin_ia32_punpcklbw (q, (v8qi) r);
+  d = r;
+  return (u64) g + (u64) h + (u64) j;
+}
+
+static void
+avx_test (void)
+{
+  u64 x = foo ((v4hi) { 5 });
+  if (x != 0x0005000500050505)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr94467-2.c 
b/gcc/testsuite/gcc.target/i386/pr94467-2.c
new file mode 100644
index 000..8128be325e4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94467-2.c
@@ -0,0 +1,48 @@
+/* { dg-do run } */
+/* { dg-require-effective-target ssse3 } */
+/* { dg-options "-O -mssse3" } */
+
+#ifndef CHECK_H
+#define CHECK_H "ssse3-check.h"
+#endif
+
+#ifndef TEST
+#define TEST ssse3_test
+#endif
+
+#include CHECK_H
+
+typedef char __attribute__ ((__vector_size__ (8))) v8qi;
+typedef short __attribute__ ((__vector_size__ (8))) v4hi;
+typedef int __attribute__ ((__vector_size__ (8))) v2si;
+typedef long long __attribute__ ((__vector_size__ (8))) v1di;
+typedef unsigned long long u64;
+u64 k, c;
+
+v8qi g, h, p, q;
+v4hi d, e, f, l, n, o;
+v2si j;
+
+u64
+foo (v4hi r)
+{
+  v8qi s;
+  f = (v4hi) j;
+  e = __builtin_ia32_psrlwi ((v4hi) k, c);
+  s = __builtin_ia32_pavgb (h, h);
+  n = __builtin_ia32_pabsw (f);
+  o = __builtin_ia32_psubusw (n, l);
+  p = __builtin_ia32_packsswb (r, o);
+  q = __builtin_ia32_pshufb (p, s);
+  g = __builtin_ia32_punpcklbw (q, (v8qi) r);
+  d = r;
+  return (u64) g + (u64) h + (u64) j;
+}
+
+static void
+ssse3_test (void)
+{
+  u64 x = foo ((v4hi) { 5 });
+  if (x != 0x0005000500050505)
+__builtin_abort ();
+}
-- 
2.25.1



Ping: [PATCH] testsuite: Tweak check-function-bodies interface

2020-04-03 Thread Richard Sandiford
Ping for the doc/sourcebuild.texi and lib/scanasm.exp parts.

Richard Sandiford  writes:
> In g:2171a9207f51bc486ed9c502cb4da706f594615e I'd tried to fix
> various ILP32 testsuite failures by restricting some tests to LP64.
> Unfortunately, I messed up the check-function-bodies syntax and passed
> the target selector as the "option" parameter, which had the effect of
> disabling the tests for both ILP32 and LP64.  "Oops."
>
> The fix ought to have been to add "" as the option parameter.  However,
> check-function-bodies wasn't treating "" in the same way as an omitted
> argument.  The easiest fix seemed to be turn the argument into a list of
> options, which also makes the interface a bit more general.
>
> Having done that, it seemed a good idea to check for things that look
> like target/xfail selectors, so that the mistake isn't silent next time.
>
> Tested on aarch64-linux-gnu and aarch64_be-elf.  OK to install?
>
> Richard

2020-03-17  Richard Sandiford  

gcc/
* doc/sourcebuild.texi (check-function-bodies): Treat the third
parameter as a list of option regexps and require each regexp
to match.

gcc/testsuite/
* lib/scanasm.exp (check-function-bodies): Treat the third
parameter as a list of option regexps and require each regexp
to match.  Check for cases in which a target/xfail selector
was mistakenly passed to the options argument.
* gcc.target/aarch64/sve/pcs/args_1.c: Add an empty options list
to the invocation of check-function-bodies.
* gcc.target/aarch64/sve/pcs/args_2.c: Likewise.
* gcc.target/aarch64/sve/pcs/args_3.c: Likewise.
* gcc.target/aarch64/sve/pcs/args_4.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_1.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_1_1024.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_1_128.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_1_2048.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_1_256.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_1_512.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_2.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_3.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_4.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_4_1024.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_4_128.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_4_2048.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_4_256.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_4_512.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_5.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_5_1024.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_5_128.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_5_2048.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_5_256.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_5_512.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_6.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_6_1024.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_6_128.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_6_2048.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_6_256.c: Likewise.
* gcc.target/aarch64/sve/pcs/return_6_512.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_2_be_nowrap.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_2_be_wrap.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_2_le_nowrap.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_2_le_wrap.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_3.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_4_be.c: Likewise.
* gcc.target/aarch64/sve/pcs/saves_4_le.c: Likewise.
* gcc.target/aarch64/sve/pcs/stack_clash_2_128.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_1.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_f16.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_f32.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_f64.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_s16.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_s32.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_s64.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_s8.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_u16.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_u32.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_u64.c: Likewise.
* gcc.target/aarch64/sve/pcs/varargs_2_u8.c: Likewise.
---
 gcc/doc/sourcebuild.texi | 12 +++-
 .../gcc.target/aarch64/sve/pcs/args_1.c  |  2 +-
 .../gcc.target/aarch64/sve/pcs/args_2.c  |  2 +-
 .../gcc.target/aarch64/sve/pcs/args_3.c  |  2 +-
 .../gcc.target/aarch64/sve/pcs/args_4.c  |  2 +-
 .../gcc.target/aarch64/sve/pcs/return_1.c|  2 +-
 

Re: [PATCH] Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3

2020-04-03 Thread Segher Boessenkool
Hi!

On Thu, Apr 02, 2020 at 08:36:59PM -0400, Michael Meissner wrote:
> I have changed the spelling of the macro to PCREL_SUPPORTED_BY_ABI (from
> PCREL_SUPPORTED_BY_OS) since you pointed out it is more properly a function of
> the particular ABI, rather than just an OS choice.

No, I did not, and that is a much worse name.  Please change it back.

The ABI does not determine *at all* whether PC-relative instructions can
be used.  Most ABIs do not use any PC-relative instructions themselves,
of course, but that is a very different thing.


Also please fix the problems Will pointed out (thanks!), and do post new
versions with the commit message you intend to use, please.


Segher


Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

2020-04-03 Thread Jan Hubicka
Hi,
and this is the streaming fix

diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index e4077b58890..dd9645723c1 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -646,6 +647,19 @@ degenerate_phi_p (gimple *phi)
   return true;
 }
 
+/* Return true if C1 and C2 are matching contexts (both translation unit decls
+   or both types.  */
+
+bool
+matching_contexts_p (tree c1, tree c2)
+{
+  if (TREE_CODE (c1) == TRANSLATION_UNIT_DECL)
+return TREE_CODE (c2) == TRANSLATION_UNIT_DECL;
+  if (TREE_CODE (c2) == TRANSLATION_UNIT_DECL)
+return TREE_CODE (c1) == TRANSLATION_UNIT_DECL;
+  return types_same_for_odr (c1, c2);
+}
+
 /* Propagate necessity using the operands of necessary statements.
Process the uses on each statement in the worklist, and add all
feeding statements which contribute to the calculation of this
@@ -824,16 +838,28 @@ propagate_necessity (bool aggressive)
   || DECL_FUNCTION_CODE (def_callee) == 
BUILT_IN_CALLOC))
  || DECL_IS_REPLACEABLE_OPERATOR_NEW_P (def_callee)))
{
- /* Delete operators can have alignment and (or) size as next
-arguments.  When being a SSA_NAME, they must be marked
-as necessary.  */
- if (is_delete_operator && gimple_call_num_args (stmt) >= 2)
-   for (unsigned i = 1; i < gimple_call_num_args (stmt); i++)
- {
-   tree arg = gimple_call_arg (stmt, i);
-   if (TREE_CODE (arg) == SSA_NAME)
- mark_operand_necessary (arg);
- }
+ if (is_delete_operator)
+   {
+ /* Verify that new and delete operators have the same
+context.  */
+ if (DECL_IS_REPLACEABLE_OPERATOR_NEW_P (def_callee)
+ && !matching_contexts_p
+(DECL_CONTEXT (def_callee),
+ DECL_CONTEXT (gimple_call_fndecl (stmt
+   mark_operand_necessary (gimple_call_arg (stmt, 0));
+
+ /* Delete operators can have alignment and (or) size
+as next arguments.  When being a SSA_NAME, they
+must be marked as necessary.  */
+ if (gimple_call_num_args (stmt) >= 2)
+   for (unsigned i = 1; i < gimple_call_num_args (stmt);
+i++)
+ {
+   tree arg = gimple_call_arg (stmt, i);
+   if (TREE_CODE (arg) == SSA_NAME)
+ mark_operand_necessary (arg);
+ }
+   }
 
  continue;
}
diff --git a/gcc/tree.c b/gcc/tree.c
index 63dc6730b2b..cd608a9c878 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -5879,6 +5879,9 @@ free_lang_data_in_decl (tree decl, class free_lang_data_d 
*fld)
  merging may merge some fileds and keep others disjoint wich in turn will
  not do well with TREE_CHAIN pointers linking them.
 
+ tree-ssa-dce is using context to match new and delete operators (which may
+ be static functions).
+
  Also do not drop containing types for virtual methods and tables because
  these are needed by devirtualization.
  C++ destructors are special because C++ frontends sometimes produces
@@ -5886,6 +5889,9 @@ free_lang_data_in_decl (tree decl, class free_lang_data_d 
*fld)
  devirutalization code we always walk through aliases and we need
  context to be preserved too.  See PR89335  */
   if (TREE_CODE (decl) != FIELD_DECL
+  && (TREE_CODE (decl) != FUNCTION_DECL
+ || (!DECL_IS_REPLACEABLE_OPERATOR_NEW_P (decl)
+ && !DECL_IS_OPERATOR_DELETE_P (decl)))
   && ((TREE_CODE (decl) != VAR_DECL && TREE_CODE (decl) != FUNCTION_DECL)
   || (!DECL_VIRTUAL_P (decl)
  && (TREE_CODE (decl) != FUNCTION_DECL


[committed] c++: Add test for PR c++/93211

2020-04-03 Thread Patrick Palka via Gcc-patches
The fix for PR c++/90711 also fixed this PR.

gcc/testsuite/ChangeLog:

PR c++/93211
PR c++/90711
* g++.dg/template/koenig11.C: New test.
---
 gcc/testsuite/g++.dg/template/koenig11.C | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/template/koenig11.C

diff --git a/gcc/testsuite/g++.dg/template/koenig11.C 
b/gcc/testsuite/g++.dg/template/koenig11.C
new file mode 100644
index 000..d69709bab59
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/koenig11.C
@@ -0,0 +1,11 @@
+// PR c++/93211
+// { dg-do compile { target c++11 } }
+
+template
+void g(T);
+
+template
+void f() {}
+
+template
+void f() {} // { dg-bogus "redefinition" }
-- 
2.26.0.106.g9fadedd637



Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

2020-04-03 Thread Jan Hubicka
> On 3/31/20 2:29 PM, Jan Hubicka wrote:
> > Well, I basically went through all pointers and tried to get rid of as
> > many of them as possible.  CONTEXT pointers do increase size of SCCs
> > that increases chance they will not get merged and also processing time
> > of merging algorithm.  I guess if we need to stream more contexts we
> > could do that (and check the effect on merging and average SCC size)
> 
> Ok, do we want to stream contexts just for the new/delete operators?
> Can you please prepare a streaming patch?
Hi,
I am still not convinced that context is useful here.
It took me a while to understand what the code does and why it fails,
but here is a testcase.
It fails for me with your patch and -O2 --param early-inlining-insns=100

The invalid transform is to remove pair
base:new and B:delete
B:new gets inlined and we get count out of sync.

Honza

#include 
volatile int idx;
struct base
{
  __attribute__((malloc,noinline))
  static void* operator new(unsigned long sz)
  {
return ::operator new(sz);
  }

  __attribute__((malloc,noinline))
  static void operator delete(void* ptr)
  {
--count[idx];
::operator delete(ptr);
  }
  volatile static int count[2];
};
volatile int base::count[2] = {0,0};
struct B:base
{
  static void* operator new(unsigned long sz)
  {
++count[idx];
return base::operator new(sz);
  }

};


volatile int c=1;

int main(){
  for (int i; i

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

2020-04-03 Thread Richard Sandiford
"Richard Earnshaw (lists)"  writes:
> On 03/04/2020 13:27, Richard Sandiford wrote:
>> "Richard Earnshaw (lists)"  writes:
>>> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
 This is attacking case 3 of PR 94174.

 In v2, I unify the various subtract-with-borrow and add-with-carry
 patterns that also output flags with unspecs.  As suggested by
 Richard Sandiford during review of v1.  It does seem cleaner.

>>>
>>> Really?  I didn't need to use any unspecs for the Arm version of this.
>>>
>>> R.
>> 
>> See https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543063.html
>> (including quoted context) for how we got here.
>> 
>> The same problem affects the existing aarch64 patterns like
>> *usub3_carryinC.  Although that pattern avoids unspecs,
>> the compare:CC doesn't seem to be correct.
>> 
>> Richard
>> 
>
> But I don't think you can use ANY_EXTEND in these comparisons.  It
> doesn't describe what the instruction does, since the instruction does
> not really extend the values first.

Yeah, that was the starting point in the thread above too.  And using
zero_extend in the existing *usub3_carryinC pattern:

(define_insn "*usub3_carryinC"
  [(set (reg:CC CC_REGNUM)
(compare:CC
  (zero_extend:
(match_operand:GPI 1 "register_operand" "r"))
  (plus:
(zero_extend:
  (match_operand:GPI 2 "register_operand" "r"))
(match_operand: 3 "aarch64_borrow_operation" ""
   (set (match_operand:GPI 0 "register_operand" "=r")
(minus:GPI
  (minus:GPI (match_dup 1) (match_dup 2))
  (match_operand:GPI 4 "aarch64_borrow_operation" "")))]
   ""
   "sbcs\\t%0, %1, %2"
  [(set_attr "type" "adc_reg")]
)

looks wrong for the same reason.  But the main problem IMO isn't how the
inputs to the compare:CC are represented, but that we're using compare:CC
at all.  Using compare doesn't accurately model the effect of SBCS on NZCV
for all inputs, so if we're going to use a compare here, it can't be :CC.

> I would really expect this patch series to be pretty much a dual of this
> series that I posted last year for Arm.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532180.html

That series uses compares with modes like CC_V and CC_B, so I think
you're saying that given the choice in the earlier thread between adding
a new CC mode or using unspecs, you would have preferred a new CC mode,
is that right?

Richard


[committed][GCC][Arm]: MVE: Fix unintended change to tests

2020-04-03 Thread Andre Vieira (lists)
When committing my last patch I accidentally removed -mfpu=auto from the 
following tests. This puts it back.


2020-04-03  Andre Vieira  

    * gcc.target/arm/mve/intrinsics/mve_vector_float.c: Put 
-mfpu=auto back.

    * gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_int.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_int1.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_int2.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
    * gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
index 
a6f95a63859c8b130f2c63f788cbea766dd8c5b2..9de47e6a1e0214fef26630b7959f11e58809d2c0
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=hard 
-mthumb --save-temps" } */
+/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
index 
7745eecacca5faa082d3440c50585f62fd34c0af..ba8fb6dd5da4464dd8e58e837d84540acd1d
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=hard 
-mthumb --save-temps" } */
+/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
index 
02653f08359176a245234448e1273fe106e324e3..3ce8ea3b303509df1ecd8096b990ea9b02846c79
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=hard 
-mthumb --save-temps" } */
+/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
index 
5c009ba746278e2bc742d5a89ca510f0899b5db2..dab07051bda3b823b2643d8d0c6aa266515a84c2
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard -mthumb 
--save-temps" } */
+/* { dg-additional-options "-march=armv8.1-m.main+mve -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c
index 
50f0bd1efa52b4b2aaf505664b3e571309a26bd3..2d2fd116dfcfcdb04220e92090706c362350e8d2
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
 /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } {""} 
} */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard -mthumb 
--save-temps" } */
+/* { dg-additional-options "-march=armv8.1-m.main+mve -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
 
 #include "arm_mve.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c
index 
11540966944614142bf46ea6953a27dff45187d4..7ec85866993f9919fc6945d056a9cf8fcf361300
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c
+++ 

Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

2020-04-03 Thread Richard Earnshaw (lists)
On 03/04/2020 13:27, Richard Sandiford wrote:
> "Richard Earnshaw (lists)"  writes:
>> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
>>> This is attacking case 3 of PR 94174.
>>>
>>> In v2, I unify the various subtract-with-borrow and add-with-carry
>>> patterns that also output flags with unspecs.  As suggested by
>>> Richard Sandiford during review of v1.  It does seem cleaner.
>>>
>>
>> Really?  I didn't need to use any unspecs for the Arm version of this.
>>
>> R.
> 
> See https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543063.html
> (including quoted context) for how we got here.
> 
> The same problem affects the existing aarch64 patterns like
> *usub3_carryinC.  Although that pattern avoids unspecs,
> the compare:CC doesn't seem to be correct.
> 
> Richard
> 

But I don't think you can use ANY_EXTEND in these comparisons.  It
doesn't describe what the instruction does, since the instruction does
not really extend the values first.

I would really expect this patch series to be pretty much a dual of this
series that I posted last year for Arm.

https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532180.html

R.


Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

2020-04-03 Thread Richard Sandiford
"Richard Earnshaw (lists)"  writes:
> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
>> This is attacking case 3 of PR 94174.
>> 
>> In v2, I unify the various subtract-with-borrow and add-with-carry
>> patterns that also output flags with unspecs.  As suggested by
>> Richard Sandiford during review of v1.  It does seem cleaner.
>> 
>
> Really?  I didn't need to use any unspecs for the Arm version of this.
>
> R.

See https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543063.html
(including quoted context) for how we got here.

The same problem affects the existing aarch64 patterns like
*usub3_carryinC.  Although that pattern avoids unspecs,
the compare:CC doesn't seem to be correct.

Richard


Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread Alan Modra via Gcc-patches
On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu via Gcc-patches wrote:
> Seems PR94393?  Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const 
> for DImode.
> I tried unsigned long like 0xabcd87654321, 0xabcd87654321 and 
> 0xc000ULL, 
> All of them are outside of loop even without my patch.  No difference with or 
> without
> Alan's patch.

Segher probably meant the part I'm working on and haven't posted yet,
fixing lots of problems with rs6000_rtx_costs.  One of the improvements
I'm aiming for is that we should be able to emit code that loads
constants from memory without following optimisation passes converting
the loads from memory to those long sequences of dependent instructions.

-- 
Alan Modra
Australia Development Lab, IBM


[PATCH] middle-end/94465 - handle released SSA names in array_ref_low_bound

2020-04-03 Thread Richard Biener
array_ref_low_bound is used in dumping ARRAY_REFs which in turn
is called when basic blocks are deleted.  cleanup_control_flow_pre
consciously decides to remove unreachable basic-blocks in arbitrary
order so the following makes array_ref_low_bound forgiving in the
case the SSA name with the index definition has been released
already.

Boostrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2020-04-03  Richard Biener  

PR middle-end/94465
* tree.c (array_ref_low_bound): Deal with released SSA names
in index position.
---
 gcc/tree.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/tree.c b/gcc/tree.c
index 63dc6730b2b..0fe3afce1b6 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -13426,7 +13426,9 @@ array_ref_low_bound (tree exp)
 return SUBSTITUTE_PLACEHOLDER_IN_EXPR (TYPE_MIN_VALUE (domain_type), exp);
 
   /* Otherwise, return a zero of the appropriate type.  */
-  return build_int_cst (TREE_TYPE (TREE_OPERAND (exp, 1)), 0);
+  tree idxtype = TREE_TYPE (TREE_OPERAND (exp, 1));
+  return (idxtype == error_mark_node
+ ? integer_zero_node : build_int_cst (idxtype, 0));
 }
 
 /* Return a tree representing the upper bound of the array mentioned in
-- 
2.13.7


Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

2020-04-03 Thread Richard Earnshaw (lists)
On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
> This is attacking case 3 of PR 94174.
> 
> In v2, I unify the various subtract-with-borrow and add-with-carry
> patterns that also output flags with unspecs.  As suggested by
> Richard Sandiford during review of v1.  It does seem cleaner.
> 

Really?  I didn't need to use any unspecs for the Arm version of this.

R.

> 
> r~
> 
> 
> Richard Henderson (11):
>   aarch64: Accept 0 as first argument to compares
>   aarch64: Accept zeros in add3_carryin
>   aarch64: Provide expander for sub3_compare1
>   aarch64: Introduce aarch64_expand_addsubti
>   aarch64: Use UNSPEC_SBCS for subtract-with-borrow + output flags
>   aarch64: Use UNSPEC_ADCS for add-with-carry + output flags
>   aarch64: Remove CC_ADCmode
>   aarch64: Accept -1 as second argument to add3_carryin
>   aarch64: Adjust result of aarch64_gen_compare_reg
>   aarch64: Implement TImode comparisons
>   aarch64: Implement absti2
> 
>  gcc/config/aarch64/aarch64-protos.h   |  10 +-
>  gcc/config/aarch64/aarch64.c  | 303 +
>  gcc/config/aarch64/aarch64-modes.def  |   1 -
>  gcc/config/aarch64/aarch64-simd.md|  18 +-
>  gcc/config/aarch64/aarch64-speculation.cc |   5 +-
>  gcc/config/aarch64/aarch64.md | 762 ++
>  gcc/config/aarch64/predicates.md  |  15 +-
>  7 files changed, 527 insertions(+), 587 deletions(-)
> 



Re: [PATCH][GCC][AArch64] opt: Fix options canonization for assembler

2020-04-03 Thread Richard Earnshaw (lists)
On 02/04/2020 17:52, Tamar Christina wrote:
> Hi All,
> 
> It is currently impossible to use fp16 on any architecture higher than 
> Armv8.3-a
> due to a bug in options canonization.  This bug results in the fp16 flag not
> being emitted in the assembly when it should have been.
> 
> This is caused by a complicated architectural requirement at Armv8.4-a.  On
> Armv8.2-a and Armv8.3-a fp16fml is an optional extension and turning it on 
> turns
> on both fp and fp16.  However starting with Armv8.4-a fp16fml is mandatory if
> fp16 is available, otherwise it's optional.
> 
> In short this means that to enable fp16fml the smallest option that needs to
> passed to the assembler is Armv8.4-a+fp16.
> 
> The fix in this patch takes into account that an option may be on by default 
> in
> an architecture, but that not all the bits required to use it are on by 
> default
> in an architecture.  In such cases the difference between the two are still
> emitted to the assembler.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for trunk? and backport to GCC 8 and 9 after some stew.
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
> 2020-04-02  Tamar Christina  
> 
>   PR target/94396
>   * common/config/aarch64/aarch64-common.c
>   (aarch64_get_extension_string_for_isa_flags): Handle default flags.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-02  Tamar Christina  
> 
>   PR target/94396
>   * gcc.target/aarch64/options_set_11.c: New test.
>   * gcc.target/aarch64/options_set_12.c: New test.
>   * gcc.target/aarch64/options_set_13.c: New test.
>   * gcc.target/aarch64/options_set_14.c: New test.
>   * gcc.target/aarch64/options_set_15.c: New test.
>   * gcc.target/aarch64/options_set_16.c: New test.
>   * gcc.target/aarch64/options_set_17.c: New test.
>   * gcc.target/aarch64/options_set_18.c: New test.
>   * gcc.target/aarch64/options_set_19.c: New test.
>   * gcc.target/aarch64/options_set_20.c: New test.
>   * gcc.target/aarch64/options_set_21.c: New test.
>   * gcc.target/aarch64/options_set_22.c: New test.
>   * gcc.target/aarch64/options_set_23.c: New test.
>   * gcc.target/aarch64/options_set_24.c: New test.
>   * gcc.target/aarch64/options_set_25.c: New test.
>   * gcc.target/aarch64/options_set_26.c: New test.
> 

OK.

R.

PS.  It's canonicalize, not canonize (this is not saintly code ;-).

R.


[Patch] HSA: omp-grid.c – access proper clause code (was: Re: [Patch] omp-grid.c – add cast to silence different enumeration types warning)

2020-04-03 Thread Tobias Burnus

Hi Jakub, hi Martin,

I think I misread some bits – after more code reading, I think it
correctly sets '(NODE)->omp_clause.code' alias OMP_CLAUSE_CODE;

Hence, using OMP_CLAUSE_CODE in the switch statement makes sense
for the actual code usage (and, of course, also semantically).

As I don't have HSA setup, I couldn't test it. This code is only
called via omp-low.c's execute_lower_omp via:
 if (hsa_gen_requested_p ())
omp_grid_gridify_all_targets ();

Hence, unsurprisingly, it did not make a difference when running
the testsuite .

OK?

[The code was added (back then to omp-low.c) in
commit 56b1c60e412fcf1245b4780871553cbdebb956a3 (r242761) with
Martins' [plural ;-)] 'Merge from HSA branch to trunk'.]

Tobias

On 4/3/20 11:08 AM, Jakub Jelinek wrote:

On Fri, Apr 03, 2020 at 11:02:13AM +0200, Tobias Burnus wrote:

Those are all for the same switch statement;

gomp_for contains 'tree clauses' and this clauses's '->code' is used
to handle store 'enum omp_clauses_code' values in in gimple.{h,c}.

I think adding this cast (and only this one) makes sense and it
also silences a (clang) compiler warning.

That looks wrong to me.  If *pc are OMP_CLAUSES, then it should use
OMP_CLAUSE_CODE (c) instead of TREE_CODE (c).
If something creates a tree that has TREE_CODE OMP_CLAUSE_LINEAR, then
that looks very suspicios (TREE_CODE should be OMP_CLAUSE).


omp-grid.c – add cast to silence different enumeration types warning

 * omp-grid.c (grid_eliminate_combined_simd_part): Add cast
 to omp_clause_code to silence compiler warning.

diff --git a/gcc/omp-grid.c b/gcc/omp-grid.c
index b98e45de6a0..878977da2f9 100644
--- a/gcc/omp-grid.c
+++ b/gcc/omp-grid.c
@@ -1058,21 +1058,21 @@ grid_eliminate_combined_simd_part (gomp_for *parloop)
while (*tgt)
  tgt = _CLAUSE_CHAIN (*tgt);

/* Copy over all clauses, except for linear clauses, which are turned into
   private clauses, and all other simd-specific clauses, which are
   ignored.  */
tree *pc = gimple_omp_for_clauses_ptr (simd);
while (*pc)
  {
tree c = *pc;
-  switch (TREE_CODE (c))
+  switch ((omp_clause_code) TREE_CODE (c))
 {
 case OMP_CLAUSE_LINEAR:
   {
 tree priv = build_omp_clause (UNKNOWN_LOCATION, OMP_CLAUSE_PRIVATE);
 OMP_CLAUSE_DECL (priv) = OMP_CLAUSE_DECL (c);
 OMP_CLAUSE_CHAIN (priv) = NULL;
 *tgt = priv;
 tgt = _CLAUSE_CHAIN (priv);
 pc = _CLAUSE_CHAIN (c);
 break;


  Jakub


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
HSA: omp-grid.c – access proper clause code

	* omp-grid.c (grid_eliminate_combined_simd_part): Use
	OMP_CLAUSE_CODE to access the omp clause code.

diff --git a/gcc/omp-grid.c b/gcc/omp-grid.c
index b98e45de6a0..ba635fd3ea2 100644
--- a/gcc/omp-grid.c
+++ b/gcc/omp-grid.c
@@ -1065,7 +1065,7 @@ grid_eliminate_combined_simd_part (gomp_for *parloop)
   while (*pc)
 {
   tree c = *pc;
-  switch (TREE_CODE (c))
+  switch (OMP_CLAUSE_CODE (c))
 	{
 	case OMP_CLAUSE_LINEAR:
 	  {


Re: Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

2020-04-03 Thread Jakub Jelinek via Gcc-patches
On Fri, Apr 03, 2020 at 11:36:29AM +0200, Richard Biener wrote:
> Note there's now also the opportunity to set the loop flag for
> OpenACC/OpenMP annotated loops if any of that guarantees finiteness.
> (for GCC11 only please)

Dunno about OpenACC, but OpenMP loops guarantee finiteness, as the number of
iterations must be computable before the loop and must fit into the type in
which that count is computed without overflows.

Jakub



Re: GCC 8 backports

2020-04-03 Thread Martin Liška

Hi.

There's one more I've tested.

Martin
>From 3b64f64f036c03e74fc4b55327cc07dc1dc21116 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 3 Apr 2020 09:39:10 +0200
Subject: [PATCH] Backport 55a7380213a5c16120d5c674fb42b38a3d796b57

gcc/ChangeLog:

2020-04-03  Martin Liska  

	PR ipa/94445
	* ipa-icf-gimple.c (func_checker::compare_gimple_call):
	  Compare type attributes for gimple_call_fntypes.
---
 gcc/ipa-icf-gimple.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index 25284936bc3..38e0ac12f7e 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-utils.h"
 #include "tree-eh.h"
 #include "builtins.h"
+#include "attribs.h"
 
 #include "ipa-icf-gimple.h"
 
@@ -768,6 +769,9 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)
   || (fntype1 && !types_compatible_p (fntype1, fntype2)))
 return return_false_with_msg ("call function types are not compatible");
 
+  if (fntype1 && fntype2 && comp_type_attributes (fntype1, fntype2) != 1)
+return return_false_with_msg ("different fntype attributes");
+
   tree chain1 = gimple_call_chain (s1);
   tree chain2 = gimple_call_chain (s2);
   if ((chain1 && !chain2)
-- 
2.26.0



Re: GCC 9 backports

2020-04-03 Thread Martin Liška

Hi.

There's one more I've tested.

Martin
>From 3b64f64f036c03e74fc4b55327cc07dc1dc21116 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 3 Apr 2020 09:39:10 +0200
Subject: [PATCH] Backport 55a7380213a5c16120d5c674fb42b38a3d796b57

gcc/ChangeLog:

2020-04-03  Martin Liska  

	PR ipa/94445
	* ipa-icf-gimple.c (func_checker::compare_gimple_call):
	  Compare type attributes for gimple_call_fntypes.
---
 gcc/ipa-icf-gimple.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index 25284936bc3..38e0ac12f7e 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-utils.h"
 #include "tree-eh.h"
 #include "builtins.h"
+#include "attribs.h"
 
 #include "ipa-icf-gimple.h"
 
@@ -768,6 +769,9 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)
   || (fntype1 && !types_compatible_p (fntype1, fntype2)))
 return return_false_with_msg ("call function types are not compatible");
 
+  if (fntype1 && fntype2 && comp_type_attributes (fntype1, fntype2) != 1)
+return return_false_with_msg ("different fntype attributes");
+
   tree chain1 = gimple_call_chain (s1);
   tree chain2 = gimple_call_chain (s2);
   if ((chain1 && !chain2)
-- 
2.26.0



Re: [committed] libstdc++: Move "free books" list from fsf.org to gnu.org

2020-04-03 Thread Jonathan Wakely via Gcc-patches

On 01/04/20 22:47 +0200, Gerald Pfeifer wrote:

The fsf.org server now has a redirect to the gnu.org server; let's
follow that.

This is my first commit to libstdc++ using git, my first squashing
(since I had a follow tweak to the ChangeLog), and my first --amend.

Please advise if I can/should do something better.


Looks fine - thanks!




[committed] libstdc++: Fix std::to_address for debug iterators (PR 93960)

2020-04-03 Thread Jonathan Wakely via Gcc-patches
It should be valid to use std::to_address on a past-the-end iterator,
but the debug mode iterators do a check for dereferenceable in their
operator->(). That check is generally useful, so rather than remove it
this changes std::__to_address to identify a debug mode iterator and
use base().operator->() to skip the check.

PR libstdc++/93960
* include/bits/ptr_traits.h (__to_address): Add special case for debug
iterators, to avoid dereferenceable check.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line number.
* testsuite/20_util/to_address/debug.cc: New test.

Tested powerpc64le-linux, committed to master.



commit 24fe8c8e338e1c820d942b9c7b997a37705eb29e
Author: Jonathan Wakely 
Date:   Fri Apr 3 10:42:20 2020 +0100

libstdc++: Fix std::to_address for debug iterators (PR 93960)

It should be valid to use std::to_address on a past-the-end iterator,
but the debug mode iterators do a check for dereferenceable in their
operator->(). That check is generally useful, so rather than remove it
this changes std::__to_address to identify a debug mode iterator and
use base().operator->() to skip the check.

PR libstdc++/93960
* include/bits/ptr_traits.h (__to_address): Add special case for 
debug
iterators, to avoid dereferenceable check.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line 
number.
* testsuite/20_util/to_address/debug.cc: New test.

diff --git a/libstdc++-v3/include/bits/ptr_traits.h 
b/libstdc++-v3/include/bits/ptr_traits.h
index 429f7fde520..8fd91bf7bf2 100644
--- a/libstdc++-v3/include/bits/ptr_traits.h
+++ b/libstdc++-v3/include/bits/ptr_traits.h
@@ -34,6 +34,10 @@
 
 #include 
 
+#if __cplusplus > 201703L
+namespace __gnu_debug { struct _Safe_iterator_base; }
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -169,7 +173,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 constexpr auto
 __to_address(const _Ptr& __ptr, _None...) noexcept
-{ return std::__to_address(__ptr.operator->()); }
+{
+  if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
+   return std::__to_address(__ptr.base().operator->());
+  else
+   return std::__to_address(__ptr.operator->());
+}
 
   /**
* @brief Obtain address referenced by a pointer to an object
diff --git a/libstdc++-v3/testsuite/20_util/to_address/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/to_address/1_neg.cc
index ceb2141f10b..ee64a2281fb 100644
--- a/libstdc++-v3/testsuite/20_util/to_address/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/to_address/1_neg.cc
@@ -17,7 +17,7 @@
 
 // { dg-options "-std=gnu++2a" }
 // { dg-do compile { target c++2a } }
-// { dg-error "not a function pointer" "" { target *-*-* } 153 }
+// { dg-error "not a function pointer" "" { target *-*-* } 157 }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/20_util/to_address/debug.cc 
b/libstdc++-v3/testsuite/20_util/to_address/debug.cc
new file mode 100644
index 000..4555284416d
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/to_address/debug.cc
@@ -0,0 +1,36 @@
+// Copyright (C) 2020 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-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+void
+test01()
+{
+  __gnu_debug::vector v{1, 2, 3};
+  auto p = std::to_address(v.end());
+  VERIFY( p == v.data() + v.size() );
+}
+
+int
+main()
+{
+  test01();
+}


Re: Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

2020-04-03 Thread Richard Biener
On Fri, 3 Apr 2020, Thomas Schwinge wrote:

> Hi!
> 
> On 2020-04-02T11:12:48+0200, Richard Biener  wrote:
> > On Wed, 1 Apr 2020, Jason Merrill wrote:
> >
> >> On 4/1/20 9:36 AM, Richard Biener wrote:
> >> > This does away with enabling -ffinite-loops at -O2+ for all languages
> >> > and instead enables it selectively for C++ only.
> 
> > I'm retesting the following [...]
> 
> ..., which got pushed in commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae
> "c/94392 - only enable -ffinite-loops for C++".
> 
> I pushed the attached in commit 4f6a0888de52a2e523a6fd4235fe7f8193819c3b
> 'Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713,
> PR94392]'.  As can be observed in two nvptx offloading test cases
> regressing, 'apparently now again "empty oacc loops are" no longer
> "removed before expand"' (quoting myself from the commit log, adapting
> Tom's commit log snippet from the reverted commit).
> 
> It's not obvious to me how the "finite loop" property discussed/changed
> in Richard's commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae "c/94392 -
> only enable -ffinite-loops for C++" relates to the previously observed
> optimization of removing "empty oacc loops [...] before expand" (after
> PR89713 commit c29c92c789d93848cc1c929838771bfc68cb272c "PR
> tree-optimization/89713 - Assume loop with an exit is finite"), but
> examining that in detail is for another day.

For C we no longer have -ffinite-loops in effect but for C++ we still
do.  But since the testcase is c/c++ common I'd have expected it
now fails "split" ... so an explicit -fno-finite-loops or
-ffinite-loops with an explanation would be easier.

Note there's now also the opportunity to set the loop flag for
OpenACC/OpenMP annotated loops if any of that guarantees finiteness.
(for GCC11 only please)

Richard.


Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

2020-04-03 Thread Jakub Jelinek via Gcc-patches
On Fri, Apr 03, 2020 at 11:13:17AM +0200, Martin Liška wrote:
> 2020-04-03  Martin Liska  
> 
>   * gcc-git-customization.sh: Search for the pattern
>   at line beginning only.

Ok, thanks.

> diff --git a/contrib/gcc-git-customization.sh 
> b/contrib/gcc-git-customization.sh
> index f3e48316ead..a932bf8c06a 100755
> --- a/contrib/gcc-git-customization.sh
> +++ b/contrib/gcc-git-customization.sh
> @@ -18,7 +18,7 @@ ask () {
>  }
>  
>  # Add a git command to find the git commit equivalent to legacy SVN revision 
> NNN
> -git config alias.svn-rev '!f() { rev=$1; shift; git log --all 
> --grep="From-SVN: r\\?$rev\\b" "${@}"; } ; f'
> +git config alias.svn-rev '!f() { rev=$1; shift; git log --all 
> --grep="^From-SVN: r\\?$rev\\b" "${@}"; } ; f'
>  
>  # Add git commands to convert git commit to monotonically increasing 
> revision number
>  # and vice versa
> 


Jakub



[PATCH] Improve svn-rev to search for pattern at line beginning.

2020-04-03 Thread Martin Liška

Hi.

It's a small fix that removes the first commit from the following command:

$ git svn-rev 279550
commit bcf3fa7cf5a3d024b507f68ffdfab037f4820781
Author: Andre Vieira 
Date:   Wed Jan 29 14:23:22 2020 +

IRA: Revert 11b8091fb to fix PR 93221

A previous change to simplify LRA introduced in 11b809 (From-SVN: r279550)

disabled hard register splitting for -O0. This causes a problem on aarch64 
in
cases where parameters are passed in multiple registers (in the bug report 
an OI
passed in 2 V4SI registers). This is mandated by the AAPCS.

gcc/ChangeLog:

2020-01-29  Joel Hutton  

PR target/93221

* ira.c (ira): Revert use of simplified LRA algorithm.

gcc/testsuite/ChangeLog:

2020-01-29  Joel Hutton  

PR target/93221

* gcc.target/aarch64/pr93221.c: New test.

commit 11b8091fb33c894cea20702d3e85389723987910
Author: Eric Botcazou 
Date:   Wed Dec 18 23:03:23 2019 +

* ira.c (ira): Use simple LRA algorithm when not optimizing.

From-SVN: r279550


Ready for master?
Martin

contrib/ChangeLog:

2020-04-03  Martin Liska  

* gcc-git-customization.sh: Search for the pattern
at line beginning only.
---
 contrib/gcc-git-customization.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index f3e48316ead..a932bf8c06a 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -18,7 +18,7 @@ ask () {
 }
 
 # Add a git command to find the git commit equivalent to legacy SVN revision NNN
-git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="From-SVN: r\\?$rev\\b" "${@}"; } ; f'
+git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="^From-SVN: r\\?$rev\\b" "${@}"; } ; f'
 
 # Add git commands to convert git commit to monotonically increasing revision number
 # and vice versa



Re: [Patch] omp-grid.c – add cast to silence different enumeration types warning

2020-04-03 Thread Jakub Jelinek via Gcc-patches
On Fri, Apr 03, 2020 at 11:02:13AM +0200, Tobias Burnus wrote:
> Those are all for the same switch statement;
> 
> gomp_for contains 'tree clauses' and this clauses's '->code' is used
> to handle store 'enum omp_clauses_code' values in in gimple.{h,c}.
> 
> I think adding this cast (and only this one) makes sense and it
> also silences a (clang) compiler warning.

That looks wrong to me.  If *pc are OMP_CLAUSES, then it should use
OMP_CLAUSE_CODE (c) instead of TREE_CODE (c).
If something creates a tree that has TREE_CODE OMP_CLAUSE_LINEAR, then
that looks very suspicios (TREE_CODE should be OMP_CLAUSE).

> omp-grid.c – add cast to silence different enumeration types warning
> 
>   * omp-grid.c (grid_eliminate_combined_simd_part): Add cast
>   to omp_clause_code to silence compiler warning.
> 
> diff --git a/gcc/omp-grid.c b/gcc/omp-grid.c
> index b98e45de6a0..878977da2f9 100644
> --- a/gcc/omp-grid.c
> +++ b/gcc/omp-grid.c
> @@ -1058,21 +1058,21 @@ grid_eliminate_combined_simd_part (gomp_for *parloop)
>while (*tgt)
>  tgt = _CLAUSE_CHAIN (*tgt);
>  
>/* Copy over all clauses, except for linear clauses, which are turned into
>   private clauses, and all other simd-specific clauses, which are
>   ignored.  */
>tree *pc = gimple_omp_for_clauses_ptr (simd);
>while (*pc)
>  {
>tree c = *pc;
> -  switch (TREE_CODE (c))
> +  switch ((omp_clause_code) TREE_CODE (c))
>   {
>   case OMP_CLAUSE_LINEAR:
> {
>   tree priv = build_omp_clause (UNKNOWN_LOCATION, OMP_CLAUSE_PRIVATE);
>   OMP_CLAUSE_DECL (priv) = OMP_CLAUSE_DECL (c);
>   OMP_CLAUSE_CHAIN (priv) = NULL;
>   *tgt = priv;
>   tgt = _CLAUSE_CHAIN (priv);
>   pc = _CLAUSE_CHAIN (c);
>   break;


Jakub



[Patch] omp-grid.c – add cast to silence different enumeration types warning

2020-04-03 Thread Tobias Burnus

Hi,

that's based on https://users.suse.com/~mliska/clang-warnings.txt
which has for omp-grid.c:

/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/omp-grid.c:1070:7:
 warning: comparison of two values with different enumeration types in switch 
statement ('enum tree_code' and 'omp_clause_code') [-Wenum-compare-switch]
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/omp-grid.c:1081:7:
 warning: comparison of two values with different enumeration types in switch 
statement ('enum tree_code' and 'omp_clause_code') [-Wenum-compare-switch]
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/omp-grid.c:1082:7:
 warning: comparison of two values with different enumeration types in switch 
statement ('enum tree_code' and 'omp_clause_code') [-Wenum-compare-switch]
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/omp-grid.c:1083:7:
 warning: comparison of two values with different enumeration types in switch 
statement ('enum tree_code' and 'omp_clause_code') [-Wenum-compare-switch]

Those are all for the same switch statement;

gomp_for contains 'tree clauses' and this clauses's '->code' is used
to handle store 'enum omp_clauses_code' values in in gimple.{h,c}.

I think adding this cast (and only this one) makes sense and it
also silences a (clang) compiler warning.

OK?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
omp-grid.c – add cast to silence different enumeration types warning

	* omp-grid.c (grid_eliminate_combined_simd_part): Add cast
	to omp_clause_code to silence compiler warning.

diff --git a/gcc/omp-grid.c b/gcc/omp-grid.c
index b98e45de6a0..878977da2f9 100644
--- a/gcc/omp-grid.c
+++ b/gcc/omp-grid.c
@@ -1058,21 +1058,21 @@ grid_eliminate_combined_simd_part (gomp_for *parloop)
   while (*tgt)
 tgt = _CLAUSE_CHAIN (*tgt);
 
   /* Copy over all clauses, except for linear clauses, which are turned into
  private clauses, and all other simd-specific clauses, which are
  ignored.  */
   tree *pc = gimple_omp_for_clauses_ptr (simd);
   while (*pc)
 {
   tree c = *pc;
-  switch (TREE_CODE (c))
+  switch ((omp_clause_code) TREE_CODE (c))
 	{
 	case OMP_CLAUSE_LINEAR:
 	  {
 	tree priv = build_omp_clause (UNKNOWN_LOCATION, OMP_CLAUSE_PRIVATE);
 	OMP_CLAUSE_DECL (priv) = OMP_CLAUSE_DECL (c);
 	OMP_CLAUSE_CHAIN (priv) = NULL;
 	*tgt = priv;
 	tgt = _CLAUSE_CHAIN (priv);
 	pc = _CLAUSE_CHAIN (c);
 	break;


Revert "[nvptx, libgomp] Update pr85381-{2, 4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

2020-04-03 Thread Thomas Schwinge
Hi!

On 2020-04-02T11:12:48+0200, Richard Biener  wrote:
> On Wed, 1 Apr 2020, Jason Merrill wrote:
>
>> On 4/1/20 9:36 AM, Richard Biener wrote:
>> > This does away with enabling -ffinite-loops at -O2+ for all languages
>> > and instead enables it selectively for C++ only.

> I'm retesting the following [...]

..., which got pushed in commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae
"c/94392 - only enable -ffinite-loops for C++".

I pushed the attached in commit 4f6a0888de52a2e523a6fd4235fe7f8193819c3b
'Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713,
PR94392]'.  As can be observed in two nvptx offloading test cases
regressing, 'apparently now again "empty oacc loops are" no longer
"removed before expand"' (quoting myself from the commit log, adapting
Tom's commit log snippet from the reverted commit).

It's not obvious to me how the "finite loop" property discussed/changed
in Richard's commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae "c/94392 -
only enable -ffinite-loops for C++" relates to the previously observed
optimization of removing "empty oacc loops [...] before expand" (after
PR89713 commit c29c92c789d93848cc1c929838771bfc68cb272c "PR
tree-optimization/89713 - Assume loop with an exit is finite"), but
examining that in detail is for another day.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 4f6a0888de52a2e523a6fd4235fe7f8193819c3b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 3 Apr 2020 10:07:16 +0200
Subject: [PATCH] Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases"
 [PR89713, PR94392]

In response to PR94392 commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae
"c/94392 - only enable -ffinite-loops for C++", this reverts PR89713
commit 00908992f2a78f213d227aea8dbab014a1361df0, as apparently now again
"empty oacc loops are" no longer "removed before expand".

	libgomp/
	PR tree-optimization/89713
	PR c/94392
	* testsuite/libgomp.oacc-c-c++-common/pr85381-2.c: Again expect
	'bar.sync'.
	* testsuite/libgomp.oacc-c-c++-common/pr85381-4.c: Likewise.
---
 libgomp/ChangeLog |  8 
 .../libgomp.oacc-c-c++-common/pr85381-2.c | 20 ++-
 .../libgomp.oacc-c-c++-common/pr85381-4.c |  5 -
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 6c437930b02f..3716f559aa1c 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,11 @@
+2020-04-03  Thomas Schwinge  
+
+	PR tree-optimization/89713
+	PR c/94392
+	* testsuite/libgomp.oacc-c-c++-common/pr85381-2.c: Again expect
+	'bar.sync'.
+	* testsuite/libgomp.oacc-c-c++-common/pr85381-4.c: Likewise.
+
 2020-03-31  Tobias Burnus  
 
 	* target.c (GOMP_target_enter_exit_data): Handle PSET/MAP_POINTER.
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-2.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-2.c
index 2cb5b95949de..6570c64afff5 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-2.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-2.c
@@ -15,4 +15,22 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-assembler-times "bar.sync" 0 } } */
+/* Todo: Boths bar.syncs can be removed.
+   Atm we generate this dead code inbetween forked and joining:
+
+ mov.u32 %r28, %ntid.y;
+ mov.u32 %r29, %tid.y;
+ add.u32 %r30, %r29, %r29;
+ setp.gt.s32 %r31, %r30, 19;
+ @%r31   bra $L2;
+ add.u32 %r25, %r28, %r28;
+ mov.u32 %r24, %r30;
+ $L3:
+ add.u32 %r24, %r24, %r25;
+ setp.le.s32 %r33, %r24, 19;
+ @%r33   bra $L3;
+ $L2:
+
+   so the loop is not recognized as empty loop (which we detect by seeing if
+   joining immediately follows forked).  */
+/* { dg-final { scan-assembler-times "bar.sync" 2 } } */
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-4.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-4.c
index e8a433ffc0a5..d955d79718df 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-4.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-4.c
@@ -21,4 +21,7 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-assembler-times "bar.sync" 0 } } */
+/* Atm, %ntid.y is broadcast from one loop to the next, so there are 2 bar.syncs
+   for that (the other two are there for the same reason as in pr85381-2.c).
+   Todo: Recompute %ntid.y instead of broadcasting it. */
+/* { dg-final { scan-assembler-times "bar.sync" 4 } } */
-- 
2.25.1



[PATCH 3/3] Remove __gcov_flush.

2020-04-03 Thread Martin Liska

gcc/ChangeLog:

2020-04-03  Martin Liska  

PR gcov-profile/93623
* tree-cfg.c (stmt_can_terminate_bb_p): Update comment to reflect
reality.

libgcc/ChangeLog:

2020-04-03  Martin Liska  

PR gcov-profile/93623
* Makefile.in: Remove __gcov_flush.
* gcov.h (__gcov_flush): Remove.
* libgcov-interface.c (__gcov_flush): Remove.
(init_mx): Use renamed mutex.
(__gcov_lock): Likewise.
(__gcov_unlock): Likewise.
(__gcov_fork): Likewise.
(__gcov_flush): Remove.
---
 gcc/tree-cfg.c |  4 ++--
 libgcc/Makefile.in |  2 +-
 libgcc/gcov.h  |  5 -
 libgcc/libgcov-interface.c | 36 +++-
 4 files changed, 10 insertions(+), 37 deletions(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index e99fb9ff5d1..b21ef0eee37 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -8439,8 +8439,8 @@ stmt_can_terminate_bb_p (gimple *t)
   && (call_flags & ECF_NOTHROW)
   && !(call_flags & ECF_RETURNS_TWICE)
   /* fork() doesn't really return twice, but the effect of
- wrapping it in __gcov_fork() which calls __gcov_flush()
-	 and clears the counters before forking has the same
+	 wrapping it in __gcov_fork() which calls __gcov_dump() and
+	 __gcov_reset() and clears the counters before forking has the same
 	 effect as returning twice.  Force a fake edge.  */
   && !fndecl_built_in_p (fndecl, BUILT_IN_FORK))
 return false;
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index e6ed153abbc..5c50f9fe4df 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -904,7 +904,7 @@ LIBGCOV_PROFILER = _gcov_interval_profiler\
 	_gcov_ior_profiler_atomic	\
 	_gcov_indirect_call_profiler_v4	\
 	_gcov_time_profiler
-LIBGCOV_INTERFACE = _gcov_dump _gcov_flush _gcov_fork			\
+LIBGCOV_INTERFACE = _gcov_dump _gcov_fork\
 	_gcov_execl _gcov_execlp	\
 	_gcov_execle _gcov_execv _gcov_execvp _gcov_execve _gcov_reset  \
 	_gcov_lock_unlock
diff --git a/libgcc/gcov.h b/libgcc/gcov.h
index f1581914dde..0e3eed31032 100644
--- a/libgcc/gcov.h
+++ b/libgcc/gcov.h
@@ -33,9 +33,4 @@ extern void __gcov_reset (void);
 
 extern void __gcov_dump (void);
 
-/* Write profile information to a file and reset counters to zero.
-   The function does operations under a mutex.  */
-
-extern void __gcov_flush (void);
-
 #endif /* GCC_GCOV_H */
diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
index 855e8612018..3a8a5bf44b8 100644
--- a/libgcc/libgcov-interface.c
+++ b/libgcc/libgcov-interface.c
@@ -28,10 +28,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #if defined(inhibit_libc)
 
-#ifdef L_gcov_flush
-void __gcov_flush (void) {}
-#endif
-
 #ifdef L_gcov_reset
 void __gcov_reset (void) {}
 #endif
@@ -42,19 +38,19 @@ void __gcov_dump (void) {}
 
 #else
 
-extern __gthread_mutex_t __gcov_flush_mx ATTRIBUTE_HIDDEN;
+extern __gthread_mutex_t __gcov_mx ATTRIBUTE_HIDDEN;
 
 #ifdef L_gcov_lock_unlock
 #ifdef __GTHREAD_MUTEX_INIT
-__gthread_mutex_t __gcov_flush_mx = __GTHREAD_MUTEX_INIT;
+__gthread_mutex_t __gcov_mx = __GTHREAD_MUTEX_INIT;
 #define init_mx_once()
 #else
-__gthread_mutex_t __gcov_flush_mx;
+__gthread_mutex_t __gcov_mx;
 
 static void
 init_mx (void)
 {
-  __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
+  __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_mx);
 }
 
 static void
@@ -71,7 +67,7 @@ void
 __gcov_lock (void)
 {
   init_mx_once ();
-  __gthread_mutex_lock (&__gcov_flush_mx);
+  __gthread_mutex_lock (&__gcov_mx);
 }
 
 /* Unlock critical section for __gcov_dump and __gcov_reset functions.  */
@@ -79,28 +75,10 @@ __gcov_lock (void)
 void
 __gcov_unlock (void)
 {
-  __gthread_mutex_unlock (&__gcov_flush_mx);
+  __gthread_mutex_unlock (&__gcov_mx);
 }
 #endif
 
-#ifdef L_gcov_flush
-/* Called before fork or exec - write out profile information gathered so
-   far and reset it to zero.  This avoids duplication or loss of the
-   profile information gathered so far.  */
-
-void
-__gcov_flush (void)
-{
-  __gcov_lock ();
-
-  __gcov_dump_int ();
-  __gcov_reset_int ();
-
-  __gcov_unlock ();
-}
-
-#endif /* L_gcov_flush */
-
 #ifdef L_gcov_reset
 
 /* Reset all counters to zero.  */
@@ -207,7 +185,7 @@ __gcov_fork (void)
   pid = fork ();
   if (pid == 0)
 {
-  __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
+  __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_mx);
   /* We do not need locking as we are the only thread in the child.  */
   __gcov_reset_int ();
 }


[PATCH 2/3] Use __gcov_dump and __gcov_reset in execv and fork context.

2020-04-03 Thread Martin Liska

libgcc/ChangeLog:

2020-04-03  Martin Liska  

PR gcov-profile/93623
* libgcov-interface.c (__gcov_fork): Do not flush
and reset only in child process.
(__gcov_execl): Dump counters only and reset them
only if exec* fails.
(__gcov_execlp): Likewise.
(__gcov_execle): Likewise.
(__gcov_execv): Likewise.
(__gcov_execvp): Likewise.
(__gcov_execve): Likewise.
---
 libgcc/libgcov-interface.c | 59 +++---
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
index a8054edba57..855e8612018 100644
--- a/libgcc/libgcov-interface.c
+++ b/libgcc/libgcov-interface.c
@@ -197,17 +197,20 @@ __gcov_dump (void)
 #endif /* L_gcov_dump */
 
 #ifdef L_gcov_fork
-/* A wrapper for the fork function.  Flushes the accumulated profiling data, so
-   that they are not counted twice.  */
+/* A wrapper for the fork function.  We reset counters in the child
+   so that they are not counted twice.  */
 
 pid_t
 __gcov_fork (void)
 {
   pid_t pid;
-  __gcov_flush ();
   pid = fork ();
   if (pid == 0)
-__GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
+{
+  __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
+  /* We do not need locking as we are the only thread in the child.  */
+  __gcov_reset_int ();
+}
   return pid;
 }
 #endif
@@ -223,7 +226,8 @@ __gcov_execl (const char *path, char *arg, ...)
   unsigned i, length;
   char **args;
 
-  __gcov_flush ();
+  /* Dump counters only, they will be lost after exec.  */
+  __gcov_dump ();
 
   va_start (ap, arg);
   va_copy (aq, ap);
@@ -239,7 +243,10 @@ __gcov_execl (const char *path, char *arg, ...)
 args[i] = va_arg (aq, char *);
   va_end (aq);
 
-  return execv (path, args);
+  int ret = execv (path, args);
+  /* We reach this code only when execv fails, reset counter then here.  */
+  __gcov_reset ();
+  return ret;
 }
 #endif
 
@@ -254,7 +261,8 @@ __gcov_execlp (const char *path, char *arg, ...)
   unsigned i, length;
   char **args;
 
-  __gcov_flush ();
+  /* Dump counters only, they will be lost after exec.  */
+  __gcov_dump ();
 
   va_start (ap, arg);
   va_copy (aq, ap);
@@ -270,7 +278,10 @@ __gcov_execlp (const char *path, char *arg, ...)
 args[i] = va_arg (aq, char *);
   va_end (aq);
 
-  return execvp (path, args);
+  int ret = execvp (path, args);
+  /* We reach this code only when execv fails, reset counter then here.  */
+  __gcov_reset ();
+  return ret;
 }
 #endif
 
@@ -286,7 +297,8 @@ __gcov_execle (const char *path, char *arg, ...)
   char **args;
   char **envp;
 
-  __gcov_flush ();
+  /* Dump counters only, they will be lost after exec.  */
+  __gcov_dump ();
 
   va_start (ap, arg);
   va_copy (aq, ap);
@@ -303,7 +315,10 @@ __gcov_execle (const char *path, char *arg, ...)
   envp = va_arg (aq, char **);
   va_end (aq);
 
-  return execve (path, args, envp);
+  int ret = execve (path, args, envp);
+  /* We reach this code only when execv fails, reset counter then here.  */
+  __gcov_reset ();
+  return ret;
 }
 #endif
 
@@ -314,8 +329,12 @@ __gcov_execle (const char *path, char *arg, ...)
 int
 __gcov_execv (const char *path, char *const argv[])
 {
-  __gcov_flush ();
-  return execv (path, argv);
+  /* Dump counters only, they will be lost after exec.  */
+  __gcov_dump ();
+  int ret = execv (path, argv);
+  /* We reach this code only when execv fails, reset counter then here.  */
+  __gcov_reset ();
+  return ret;
 }
 #endif
 
@@ -326,8 +345,12 @@ __gcov_execv (const char *path, char *const argv[])
 int
 __gcov_execvp (const char *path, char *const argv[])
 {
-  __gcov_flush ();
-  return execvp (path, argv);
+  /* Dump counters only, they will be lost after exec.  */
+  __gcov_dump ();
+  int ret = execvp (path, argv);
+  /* We reach this code only when execv fails, reset counter then here.  */
+  __gcov_reset ();
+  return ret;
 }
 #endif
 
@@ -338,8 +361,12 @@ __gcov_execvp (const char *path, char *const argv[])
 int
 __gcov_execve (const char *path, char *const argv[], char *const envp[])
 {
-  __gcov_flush ();
-  return execve (path, argv, envp);
+  /* Dump counters only, they will be lost after exec.  */
+  __gcov_dump ();
+  int ret = execve (path, argv, envp);
+  /* We reach this code only when execv fails, reset counter then here.  */
+  __gcov_reset ();
+  return ret;
 }
 #endif
 #endif /* inhibit_libc */


[PATCH 1/3] Do locking for __gcov_dump and __gcov_reset as well.

2020-04-03 Thread Martin Liska

libgcc/ChangeLog:

2020-04-03  Martin Liska  

PR gcov-profile/93623
* Makefile.in: Add _gcov_lock_unlock to LIBGCOV_INTERFACE.
* libgcov-interface.c (ALIAS_void_fn): Remove.
(__gcov_lock): New.
(__gcov_unlock): New.
(__gcov_flush): Use __gcov_lock and __gcov_unlock.
(__gcov_reset): Likewise.
(__gcov_dump): Likewise.
* libgcov.h (__gcov_lock): New declaration.
(__gcov_unlock): Likewise.
---
 libgcc/Makefile.in |  3 +-
 libgcc/libgcov-interface.c | 59 --
 libgcc/libgcov.h   |  6 
 3 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 851e7657d07..e6ed153abbc 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -906,7 +906,8 @@ LIBGCOV_PROFILER = _gcov_interval_profiler\
 	_gcov_time_profiler
 LIBGCOV_INTERFACE = _gcov_dump _gcov_flush _gcov_fork			\
 	_gcov_execl _gcov_execlp	\
-	_gcov_execle _gcov_execv _gcov_execvp _gcov_execve _gcov_reset
+	_gcov_execle _gcov_execv _gcov_execvp _gcov_execve _gcov_reset  \
+	_gcov_lock_unlock
 LIBGCOV_DRIVER = _gcov
 
 libgcov-merge-objects = $(patsubst %,%$(objext),$(LIBGCOV_MERGE))
diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
index 048b9029ff3..a8054edba57 100644
--- a/libgcc/libgcov-interface.c
+++ b/libgcc/libgcov-interface.c
@@ -42,18 +42,9 @@ void __gcov_dump (void) {}
 
 #else
 
-/* Some functions we want to bind in this dynamic object, but have an
-   overridable global alias.  Unfortunately not all targets support
-   aliases, so we just have a forwarding function.  That'll be tail
-   called, so the cost is a single jump instruction.*/
-
-#define ALIAS_void_fn(src,dst) \
-  void dst (void)	\
-  { src (); }
-
 extern __gthread_mutex_t __gcov_flush_mx ATTRIBUTE_HIDDEN;
 
-#ifdef L_gcov_flush
+#ifdef L_gcov_lock_unlock
 #ifdef __GTHREAD_MUTEX_INIT
 __gthread_mutex_t __gcov_flush_mx = __GTHREAD_MUTEX_INIT;
 #define init_mx_once()
@@ -74,6 +65,25 @@ init_mx_once (void)
 }
 #endif
 
+/* Lock critical section for __gcov_dump and __gcov_reset functions.  */
+
+void
+__gcov_lock (void)
+{
+  init_mx_once ();
+  __gthread_mutex_lock (&__gcov_flush_mx);
+}
+
+/* Unlock critical section for __gcov_dump and __gcov_reset functions.  */
+
+void
+__gcov_unlock (void)
+{
+  __gthread_mutex_unlock (&__gcov_flush_mx);
+}
+#endif
+
+#ifdef L_gcov_flush
 /* Called before fork or exec - write out profile information gathered so
far and reset it to zero.  This avoids duplication or loss of the
profile information gathered so far.  */
@@ -81,13 +91,12 @@ init_mx_once (void)
 void
 __gcov_flush (void)
 {
-  init_mx_once ();
-  __gthread_mutex_lock (&__gcov_flush_mx);
+  __gcov_lock ();
 
   __gcov_dump_int ();
   __gcov_reset_int ();
 
-  __gthread_mutex_unlock (&__gcov_flush_mx);
+  __gcov_unlock ();
 }
 
 #endif /* L_gcov_flush */
@@ -143,7 +152,17 @@ __gcov_reset_int (void)
 }
 }
 
-ALIAS_void_fn (__gcov_reset_int, __gcov_reset);
+/* Exported function __gcov_reset.  */
+
+void
+__gcov_reset (void)
+{
+  __gcov_lock ();
+
+  __gcov_reset_int ();
+
+  __gcov_unlock ();
+}
 
 #endif /* L_gcov_reset */
 
@@ -163,7 +182,17 @@ __gcov_dump_int (void)
 __gcov_dump_one (root);
 }
 
-ALIAS_void_fn (__gcov_dump_int, __gcov_dump);
+/* Exported function __gcov_dump.  */
+
+void
+__gcov_dump (void)
+{
+  __gcov_lock ();
+
+  __gcov_dump_int ();
+
+  __gcov_unlock ();
+}
 
 #endif /* L_gcov_dump */
 
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 023293e05ec..104b80bdcbb 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -253,6 +253,12 @@ extern void __gcov_reset_int (void) ATTRIBUTE_HIDDEN;
 /* User function to enable early write of profile information so far.  */
 extern void __gcov_dump_int (void) ATTRIBUTE_HIDDEN;
 
+/* Lock critical section for __gcov_dump and __gcov_reset functions.  */
+extern void __gcov_lock (void) ATTRIBUTE_HIDDEN;
+
+/* Unlock critical section for __gcov_dump and __gcov_reset functions.  */
+extern void __gcov_unlock (void) ATTRIBUTE_HIDDEN;
+
 /* The merge function that just sums the counters.  */
 extern void __gcov_merge_add (gcov_type *, unsigned) ATTRIBUTE_HIDDEN;
 


[stage1][PATCH 0/3] __gcov_dump improvements

2020-04-03 Thread Martin Liska
Hi.

The following mini patch series improves:
- gcov run-time locking is used for user accessible __gcov_dump and 
__gcov_reset functions
- do not run __gcov_flush in fork, only __gcov_reset is called in child process
- gcov exec* wrappers dump counters and reset only if execv* fails

Patch can bootstrap on x86_64-linux-gnu and survives regression tests. 
I'll install the patch set in next stage1 if there are no objections.

Thanks,
Martin

Martin Liska (3):
  Do locking for __gcov_dump and __gcov_reset as well.
  Use __gcov_dump and __gcov_reset in execv and fork context.
  Remove __gcov_flush.

 gcc/tree-cfg.c |   4 +-
 libgcc/Makefile.in |   5 +-
 libgcc/gcov.h  |   5 --
 libgcc/libgcov-interface.c | 126 +++--
 libgcc/libgcov.h   |   6 ++
 5 files changed, 91 insertions(+), 55 deletions(-)

-- 
2.26.0



Re: [PATCH] gcc-9 sra: Cap number of sub-access propagations with a param (PR 93435)

2020-04-03 Thread Richard Biener
On Thu, 2 Apr 2020, Martin Jambor wrote:

> Hi,
> 
> This is non-trivial but rather straightforward backport of
> 29f23ed79b60949fc60f6fdbbd931bd58090b241 from master.  See
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for
> more information.
> 
> Bootstrapped and tested on gcc-9 branch, can I commit it there?  It also
> applies as-is to gcc-8 as well and I will backport it there as the next
> step after testing (without seeking another approval).

OK.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> 
> 2020-04-01  Martin Jambor  
> 
>   PR tree-optimization/93435
>   * params.def (PARAM_SRA_MAX_PROPAGATIONS): New parameter.
>   * tree-sra.c (propagation_budget): New variable.
>   (budget_for_propagation_access): New function.
>   (propagate_subaccesses_across_link): Use it.
>   (propagate_all_subaccesses): Set up and destroy propagation_budget.
>   * doc/invoke.texi (sra-max-propagations): New.
> 
>   gcc/testsuite/
>   * gcc.dg/tree-ssa/pr93435.c: New test.
> ---
>  gcc/ChangeLog   |  10 ++
>  gcc/doc/invoke.texi |   5 +
>  gcc/params.def  |   7 ++
>  gcc/testsuite/ChangeLog |   5 +
>  gcc/testsuite/gcc.dg/tree-ssa/pr93435.c | 159 
>  gcc/tree-sra.c  |  34 -
>  6 files changed, 219 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr93435.c
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 2b1ce7df14a..815fa8eec2d 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,13 @@
> +2020-04-01  Martin Jambor  
> +
> + PR tree-optimization/93435
> + * params.def (PARAM_SRA_MAX_PROPAGATIONS): New parameter.
> + * tree-sra.c (propagation_budget): New variable.
> + (budget_for_propagation_access): New function.
> + (propagate_subaccesses_across_link): Use it.
> + (propagate_all_subaccesses): Set up and destroy propagation_budget.
> + * doc/invoke.texi (sra-max-propagations): New.
> +
>  2020-03-31  Carl Love  
>  
>   Backport of:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 0f6247caf51..1782a648d02 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -11797,6 +11797,11 @@ speed
>  (@option{sra-max-scalarization-size-Ospeed}) or size
>  (@option{sra-max-scalarization-size-Osize}) respectively.
>  
> +@item sra-max-propagations
> +The maximum number of artificial accesses that Scalar Replacement of
> +Aggregates (SRA) will track, per one local variable, in order to
> +facilitate copy propagation.
> +
>  @item tm-max-aggregate-size
>  When making copies of thread-local variables in a transaction, this
>  parameter specifies the size in bytes after which variables are
> diff --git a/gcc/params.def b/gcc/params.def
> index 8e4887e50a2..e23a4530bfa 100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -1081,6 +1081,13 @@ DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE,
> "considered for scalarization when compiling for size.",
> 0, 0, 0)
>  
> +DEFPARAM (PARAM_SRA_MAX_PROPAGATIONS,
> +   "sra-max-propagations",
> +   "Maximum number of artificial accesses to enable forward propagation "
> +   "that Scalar Replacement of Aggregates will keep for one local "
> +   "variable.",
> +   32, 0, 0)
> +
>  DEFPARAM (PARAM_IPA_CP_VALUE_LIST_SIZE,
> "ipa-cp-value-list-size",
> "Maximum size of a list of values associated with each parameter for "
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 71686c72a33..6be82b5d5c2 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-04-01  Martin Jambor  
> +
> + PR tree-optimization/93435
> + * gcc.dg/tree-ssa/pr93435.c: New test.
> +
>  2020-03-28  Tobias Burnus  
>  
>   Backport from mainline
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr93435.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr93435.c
> new file mode 100644
> index 000..cb8e7495b15
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr93435.c
> @@ -0,0 +1,159 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +typedef signed char int8_T;
> +typedef int int32_T;
> +
> +typedef struct {
> +  int8_T a;
> +} struct0_T;
> +
> +typedef struct {
> +  struct0_T f10[4];
> +} struct_T;
> +
> +typedef struct {
> +  struct_T f9[4];
> +} b_struct_T;
> +
> +typedef struct {
> +  b_struct_T f8[4];
> +} c_struct_T;
> +
> +typedef struct {
> +  c_struct_T f7[4];
> +} d_struct_T;
> +
> +typedef struct {
> +  d_struct_T f6[4];
> +} e_struct_T;
> +
> +typedef struct {
> +  e_struct_T f5[4];
> +} f_struct_T;
> +
> +typedef struct {
> +  f_struct_T f4[4];
> +} g_struct_T;
> +
> +typedef struct {
> +  g_struct_T f3[4];
> +} h_struct_T;
> +
> +typedef struct {
> +  h_struct_T f2[4];
> +} i_struct_T;
> +
> +typedef struct {
> +  i_struct_T f1[4];
> +} j_struct_T;
> +
> +typedef struct {
> +  struct {

Re: [PATCH] ICF: compare type attributes for gimple_call_fntypes.

2020-04-03 Thread Martin Liška

On 4/2/20 7:17 PM, Christophe Lyon wrote:

On Thu, 2 Apr 2020 at 17:16, Martin Liška  wrote:


Hi.

The patch compares type attributes for gimple_call_fntypes in IPA ICF.
Note that we were unable to find a generic function attribute that
can be used on a function type definition.

For a one which is allowed assume_aligned(16) I get affects_type_identity == 
false
which seems suspicious to me.

Note that we currently use comp_type_attributes in ICF for both variable and
function declarations.

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

Ready to be installed?
Thanks,
Martin



Hi,

Thanks for the quick patch!


Hi.

Good!



I confirm it fixes the problem I noticed on arm with the cmse-15.c for
-O2 and -O3.

However, the testcase still fails with -Os. I haven't looked at the
details, so it may be a different cause.


I analyzed that slightly and there are still IPA ICF merged that happen
(this time valid transformations):

/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c:14:5: 
optimized: Semantic equality hit:nonsecure0/4->nonsecure2/6
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c:14:5: 
optimized: Assembler symbol names:nonsecure0/4->nonsecure2/6

/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c:33:5: 
optimized: Semantic equality hit:secure0/8->secure2/10
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c:33:5: 
optimized: Assembler symbol names:secure0/8->secure2/10

and with -Os nosecure2 -> mosecure0 call is not inlined bad again. That makes 
the scanning pattern to miss:

-Os version:
nonsecure2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
b   nonsecure0

-O2 version:
nonsecure2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
lsrsr0, r0, #1
lslsr0, r0, #1
mov r1, r0
mov r2, r0
mov r3, r0
bl  __gnu_cmse_nonsecure_call

Martin



Thanks,

Christophe


gcc/ChangeLog:

2020-04-02  Martin Liska  

 PR ipa/94445
 * ipa-icf-gimple.c (func_checker::compare_gimple_call):
   Compare type attributes for gimple_call_fntypes.
---
   gcc/ipa-icf-gimple.c | 4 
   1 file changed, 4 insertions(+)






Re: [PATCH] Fix PR94443 with gsi_insert_seq_before

2020-04-03 Thread Richard Biener via Gcc-patches
On Thu, Apr 2, 2020 at 12:43 PM Kewen.Lin  wrote:
>
> on 2020/4/2 上午6:51, H.J. Lu wrote:
> >
> > This caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94449
> >
>
> Thanks for reporting this.  The attached patch is to fix the stupid
> mistake by using gsi_insert_seq_before instead of gsi_insert_before.
>
> BTW, the regression testing on one x86_64 machine from CFarm is
> unable to reveal it (I guess due to native arch sandybridge?), so I
> specified additional option -march=znver2 and verified the coverage.
>
> Bootstrapped/regtested on powerpc64le-linux-gnu (P9) and
> x86_64-pc-linux-gnu, also verified the fail cases in related PRs.

OK.

Richard.

>
> BR,
> Kewen
> ---
> gcc/ChangeLog
>
> 2020-04-02  Kewen Lin  
>
> PR tree-optimization/94443
> * tree-vect-loop.c (vectorizable_live_operation): Use
> gsi_insert_seq_before to replace gsi_insert_before.
>
> gcc/testsuite/ChangeLog
>
> 2020-04-02  Kewen Lin  
>
> PR tree-optimization/94443
> * gcc.dg/vect/pr94443.c: New test.
>


Re: [PATCH] ICF: compare type attributes for gimple_call_fntypes.

2020-04-03 Thread Richard Biener via Gcc-patches
On Thu, Apr 2, 2020 at 5:16 PM Martin Liška  wrote:
>
> Hi.
>
> The patch compares type attributes for gimple_call_fntypes in IPA ICF.
> Note that we were unable to find a generic function attribute that
> can be used on a function type definition.
>
> For a one which is allowed assume_aligned(16) I get affects_type_identity == 
> false
> which seems suspicious to me.
>
> Note that we currently use comp_type_attributes in ICF for both variable and
> function declarations.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

OK.

Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-04-02  Martin Liska  
>
> PR ipa/94445
> * ipa-icf-gimple.c (func_checker::compare_gimple_call):
>   Compare type attributes for gimple_call_fntypes.
> ---
>   gcc/ipa-icf-gimple.c | 4 
>   1 file changed, 4 insertions(+)
>
>


[Committed] S/390 zTPF: Handle skip trace addresses when unwinding

2020-04-03 Thread Andreas Krebbel via Gcc-patches
From: Jim Johnston 

Check for and handle new skip trace addresses when unwinding on zTPF.

libgcc/ChangeLog:

2020-04-03  Jim Johnston  

* config/s390/tpf-unwind.h (MIN_PATRANGE, MAX_PATRANGE)
(TPFRA_OFFSET): Macros removed.
(CP_CNF, cinfc_fast, CINFC_CMRESET, CINTFC_CMCENBKST)
(CINTFC_CMCENBKED, ICST_CRET, ICST_SRET, LOWCORE_PAGE3_ADDR)
(PG3_SKIPPING_OFFSET): New macros.
(__isPATrange): Use cinfc_fast for the check.
(__isSkipResetAddr): New function.
(s390_fallback_frame_state): Check for skip trace addresses. Use
either ICST_CRET or ICST_SRET to calculate return address
location.
(__tpf_eh_return): Handle skip trace addresses.
---
 libgcc/ChangeLog|  14 
 libgcc/config/s390/tpf-unwind.h | 132 ++--
 2 files changed, 89 insertions(+), 57 deletions(-)

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index c5ff4f63c7d..7548e347640 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,17 @@
+2020-04-03  Jim Johnston  
+
+   * config/s390/tpf-unwind.h (MIN_PATRANGE, MAX_PATRANGE)
+   (TPFRA_OFFSET): Macros removed.
+   (CP_CNF, cinfc_fast, CINFC_CMRESET, CINTFC_CMCENBKST)
+   (CINTFC_CMCENBKED, ICST_CRET, ICST_SRET, LOWCORE_PAGE3_ADDR)
+   (PG3_SKIPPING_OFFSET): New macros.
+   (__isPATrange): Use cinfc_fast for the check.
+   (__isSkipResetAddr): New function.
+   (s390_fallback_frame_state): Check for skip trace addresses. Use
+   either ICST_CRET or ICST_SRET to calculate return address
+   location.
+   (__tpf_eh_return): Handle skip trace addresses.
+
 2020-03-26  Richard Earnshaw  
 
PR target/94220
diff --git a/libgcc/config/s390/tpf-unwind.h b/libgcc/config/s390/tpf-unwind.h
index 2bd5493bb71..fadc06b5e59 100644
--- a/libgcc/config/s390/tpf-unwind.h
+++ b/libgcc/config/s390/tpf-unwind.h
@@ -32,20 +32,29 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
Description: This function simply checks to see if the address
passed to it is in the CP pat code range.  */
 
-#define MIN_PATRANGE 0x1
-#define MAX_PATRANGE 0x80
+#define CP_CNF  0xc18u /* location of BSS CINFC pointer */
+#define cinfc_fast(TAG) (void *) \
+  *((unsigned long *) *(unsigned long *) (CP_CNF) + (TAG))
+#define CINFC_CMRESET 187
+#define CINTFC_CMCENBKST 431
+#define CINTFC_CMCENBKED 432
 
 static inline unsigned int
 __isPATrange (void *addr)
 {
-  if (addr > (void *)MIN_PATRANGE && addr < (void *)MAX_PATRANGE)
-return 1;
-  else
-return 0;
+  return !!(addr > cinfc_fast (CINTFC_CMCENBKST)
+   && addr < cinfc_fast (CINTFC_CMCENBKED));
+}
+
+static inline unsigned int
+__isSkipResetAddr (void *addr)
+{
+  return !!(addr == cinfc_fast (CINFC_CMRESET));
 }
 
 /* TPF return address offset from start of stack frame.  */
-#define TPFRA_OFFSET 168
+#define ICST_CRET 168
+#define ICST_SRET 320
 
 /* Exceptions macro defined for TPF so that functions without
dwarf frame information can be used with exceptions.  */
@@ -63,12 +72,12 @@ s390_fallback_frame_state (struct _Unwind_Context *context,
 (((unsigned long int) context->cfa) - STACK_POINTER_OFFSET));
 
   /* Are we going through special linkage code?  */
-  if (__isPATrange (context->ra))
+  if (__isPATrange (context->ra) || __isSkipResetAddr (context->ra))
 {
 
   /* Our return register isn't zero for end of stack, so
  check backward stackpointer to see if it is zero.  */
-  if (regs == NULL)
+  if (regs == 0)
  return _URC_END_OF_STACK;
 
   /* No stack frame.  */
@@ -83,11 +92,18 @@ s390_fallback_frame_state (struct _Unwind_Context *context,
  fs->regs.reg[i].loc.reg = i;
}
 
-  /* ... except for %r14, which is stored at CFA-112
-and used as return address.  */
-  fs->regs.reg[14].how = REG_SAVED_OFFSET;
-  fs->regs.reg[14].loc.offset = TPFRA_OFFSET - STACK_POINTER_OFFSET;
-  fs->retaddr_column = 14;
+  /* ... except for %r14, which is stored at CFA+offset where offset
+is displacment of ICST_CRET or ICST_SRET from CFA */
+  if ( __isPATrange(context->ra) )  {
+  fs->regs.reg[14].how = REG_SAVED_OFFSET;
+  fs->regs.reg[14].loc.offset = ICST_CRET - STACK_POINTER_OFFSET;
+  fs->retaddr_column = 14;
+  }  else  {
+  fs->regs.reg[14].how = REG_SAVED_OFFSET;
+  fs->regs.reg[14].loc.offset = ICST_SRET - STACK_POINTER_OFFSET;
+  fs->retaddr_column = 14;
+
+  }
 
   return _URC_NO_REASON;
 }
@@ -140,6 +156,9 @@ s390_fallback_frame_state (struct _Unwind_Context *context,
 #define TPFAREA_SIZE STACK_POINTER_OFFSET-TPFAREA_OFFSET
 #define INVALID_RETURN 0
 
+#define LOWCORE_PAGE3_ADDR 4032
+#define PG3_SKIPPING_OFFSET 18
+
 void * __tpf_eh_return (void *target, void *origRA);
 
 void *
@@ -148,30 +167,29 @@ __tpf_eh_return (void *target, void *origRA)
   Dl_info 

[PATCH v2] gcc/config/rs6000: Add link with libc128 with -mlong-double-128 for AIX

2020-04-03 Thread CHIGOT, CLEMENT via Gcc-patches
Description:
 * AIX applications using 128-bit long double must be linked with
   libc128.a, in order to have 128-bit compatible routines.

Tests:
 * AIX 7.2, 7.1, 6.1: Build/Tests: OK

Changelog:
2020-04-03 Clément Chigot 
 * config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128.
 * config/rs6000/aix71.h (LIB_SPEC): Likewise.
 * config/rs6000/aix72.h (LIB_SPEC): Likewise.





gcc-8.4.0-gcc-config-rs6000-add-link-with-libc128-with-mlong-d.patch
Description: gcc-8.4.0-gcc-config-rs6000-add-link-with-libc128-with-mlong-d.patch


Re: [PATCH] Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3

2020-04-03 Thread will schmidt via Gcc-patches
On Thu, 2020-04-02 at 20:36 -0400, Michael Meissner via Gcc-patches
wrote:
> Enable -mpcrel on PowerPC -mcpu=future ELF v2 systems, V3
> 

Hi,

> This patch changes the default for -mcpu=future to be -mpcrel (i.e.
> use
> PC-relative addressing) if the ABI allows PC-relative relocations and
> the user
> did not use either -mno-pcrel or -mno-prefixed.
> 
> I have changed the spelling of the macro to PCREL_SUPPORTED_BY_ABI
> (from
> PCREL_SUPPORTED_BY_OS) since you pointed out it is more properly a
> function of
> the particular ABI, rather than just an OS choice.  I have changed
> the various
> comments to make it clearer.
> 
> I have done a bootstrap and a make check with and without the patch
> and there
> were no regressions by adding the patch on a little endian PowerPC
> Linux
> system.
> 
> I also tested by hand that if I use:
> 
>   -mcpu=power9
>   -mcpu=future -mno-prefixed
>   -mcpu=future -mno-pcrel
>   -mcpu=future -mabi=elfv1(or)
>   -mcpu=future -mcmodel=large
> 
> that PC-relative addressing is not enabled by default.  Variants of
> this patch
> have been used since December, building power8/power9 code on big
> endian
> systems, and power8/power9/future on little endian systems.  Can I
> check this
> into the master branch?
> 
> 2020-04-02  Michael Meissner  
> 
>   * config/rs6000/linux64.h (PCREL_SUPPORTED_BY_ABI): Enable
>   prefixed PC-relative addressing if the ABI supports it.

>   * config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Do
> not
>   set OPTION_MASK_FUTURE here.

Patch contents suggest this should be "Do not set OPTION_MASK_PREFIXED
here."

>   * config/rs6000/rs6000.c (rs6000_option_override_internal):
> Enable
>   OPTION_MASK_PREFIXED and OPTION_MASK_PREFIXED on -mcpu=future
> by
>   default if the current ABI allows the options.

It's so good we enable it twice.  :-)
One of those should be s/OPTION_MASK_PREFIXED/OPTION_MASK_PCREL/


> 
> --- /tmp/IPB30g_linux64.h 2020-04-02 15:23:19.977060411 -0500
> +++ gcc/config/rs6000/linux64.h   2020-04-02 15:23:01.016474023
> -0500
> @@ -640,3 +640,11 @@ extern int dot_symbols;
> enabling the __float128 keyword.  */
>  #undef   TARGET_FLOAT128_ENABLE_TYPE
>  #define TARGET_FLOAT128_ENABLE_TYPE 1
> +
> +/* Enable using prefixed PC-relative addressing on the 'future'
> machine if the
> +   ABI supports it.  The ELF v2 ABI only supports PC-relative
> relocations for
> +   the medium code model.  */
> +#undef  PCREL_SUPPORTED_BY_ABI

A previous comment suggested the #undef there should not be there. 
(potential for hiding or introducing a bug).


Thanks
-Will





Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread luoxhu via Gcc-patches



On 2020/4/3 06:16, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Mar 30, 2020 at 11:59:57AM +0800, luoxhu wrote:
>>> Do we want something later in the RTL pipeline to make "addi"s etc. again?
> 
> (This would be a good thing to consider -- maybe a define_insn_and_split
> will work.  But see below).
> 
>> [PATCH] rs6000: Don't split constant operator add before reload, move to 
>> temp register for future optimization
>>
>> Don't split code from add3 for SDI to allow a later pass to split.
>> This allows later logic to hoist out constant load in add instructions.
>> In loop, lis+ori could be hoisted out to improve performance compared with
>> previous addis+addi (About 15% on typical case), weak point is
>> one more register is used and one more instruction is generated.  i.e.:
>>
>> addis 3,3,0x8765
>> addi 3,3,0x4321
>>
>> =>
>>
>> lis 9,0x8765
>> ori 9,9,0x4321
>> add 3,3,9
> 
> (This patch will of course have to wait for stage 1).
> 
> Such a define_insn_and_split could be for an add of a (signed) 32-bit
> immediate.  combine will try to combine the three insns (lis;ori;add),
> and match the new pattern.

Currently 286r.split2 will split "12:%9:DI=0x87654321" to lis+ori by
rs6000_emit_set_const of define_split, do you mean add new define_insn_and_split
to do the split?  Another patch to do this after this one goes upstream in 
stage 1?

> 
> This also links in with Alan's work on big immediates, and with paddi
> insns, etc.

Seems PR94393?  Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const for 
DImode.
I tried unsigned long like 0xabcd87654321, 0xabcd87654321 and 
0xc000ULL, 
All of them are outside of loop even without my patch.  No difference with or 
without
Alan's patch.

0xabcd87654321: li 9,0  ori 9,9,0xabcd  sldi 9,9,32   oris 9,9,0x8765ori 
9,9,0x4321
0xabcd87654321: lis 9,0xabcd   ori 9,9,0x8765 sldi 9,9,16 ori 
9,9,0x4321
0xc000ULL:   li 9,-1   rldicr 9,9,0,1


Thanks,
Xionghu

> 
> 
> Segher
>